Cram Sheet260 words
Topic 5.1 — Configuring monitoring — cram sheet
Topic 5.1 — Configuring monitoring · cram sheet
Metrics vs logs
| Type | Use | Queried with |
|---|---|---|
| Metrics | Fast alerting | Metrics explorer |
| Logs | Investigation | KQL |
Alert on metrics, investigate in logs. Logs live in a Log Analytics workspace.
Both directions
- Pipeline → Monitor: release annotations put deployments on the telemetry chart.
- Monitor → Pipeline: the Query Azure Monitor alerts check blocks deployment to an unhealthy target.
Telemetry products
| Product | Collects |
|---|---|
| Application Insights | Requests, dependencies, exceptions, traces |
| VM Insights | VM performance + dependency map |
| Container Insights | AKS / container performance |
| Azure Monitor for Storage | Storage performance/availability |
| Azure Monitor for Networks | Network health |
Application question → Application Insights. Infrastructure question → VM/Container Insights. Sampling keeps statistical shape and loses individual events — know the rate before promising per-transaction traceability.
GitHub monitoring
- Insights cover the repository and pipeline, not runtime application health.
- The dependency graph determines which advisories apply — it underpins Dependabot. An unparsed manifest = no alerts, indistinguishable from no vulnerabilities.
- Actions usage = run duration and failure rate.
Alerting on pipeline events
- Alert on: broken
main· awaiting approval · production release failure. - A notification step needs
condition: failed()— the implicitsucceeded()skips it after a failure, and the silence reads as good news. - Route to a team that can act; ownership must be explicit.