Azure / Intermediate: managed services and governance / Lesson 10

Azure Monitor and meaningful observability

Connect metrics, logs, traces, and alerts to an observable user outcome. Distinguish control-plane activity from application and data-plane evidence, and keep telemetry scope and cost explicit.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Define a telemetry source, destination, and interpretation.
Use denominators and alert ownership correctly.
Protect sensitive context and state collection limits.

Different signals answer different questions

Azure Monitor brings together monitoring capabilities, while services such as Application Insights and Log Analytics support particular application and log-analysis workflows. Metrics summarize measured values, logs describe events or records, and distributed tracing can connect stages of an operation. Azure Activity Log describes supported control-plane activity; it is not a complete audit of every data read or business action. Service diagnostic settings and other collection paths must be designed explicitly. A resource existing does not prove its useful logs were collected, retained, or queried. Name the exact user outcome before deciding which signal will establish it.

A telemetry pipeline needs end-to-end ownership

Record the source, collection mechanism, destination workspace or store, access scope, retention, and expected delay. Missing data can mean no event occurred, collection failed, routing was wrong, retention expired, or the query selected a different scope. The JSON plan below distinguishes an API completion event from control-plane changes and assigns an owner to investigate each. It is not a diagnostic-setting deployment. A real implementation must verify table/schema details and regional or service support, then confirm a known synthetic event reaches the intended destination without leaking private payloads. Plan telemetry ingestion and retention as resource decisions too.

json A synthetic telemetry ownership plan

{
  "model": "telemetry-plan-only",
  "signals": [
    {
      "source": "application",
      "event": "document_completed",
      "owner": "application-team"
    },
    {
      "source": "control-plane",
      "event": "resource_configuration_change",
      "owner": "platform-team"
    }
  ],
  "verify": [
    "collection",
    "destination",
    "scope",
    "retention",
    "known-event-arrival"
  ]
}

Expected output

control-plane changes and application completion need separate evidence

The plan does not enable collection or establish that any Azure event exists. No workspace or account is queried.

Every percentage needs a population

A request error rate needs a defined operation, time window, eligibility rule, and denominator. Do not count only successful responses in a latency report while omitting timeouts from failure reporting. A queued task can fail after an HTTP acceptance, so measure completion separately. The offline program counts one server-status failure among four synthetic observations; it is not a measured service-level indicator. A real SLI might also include domain failures, rejected valid requests, or excessive delay according to the user promise. Avoid averaging percentiles or comparing scopes with incompatible definitions just because both appear on a dashboard.

python Offline failure-count interpretation

statuses = [200, 202, 503, 200]
failures = sum(status >= 500 for status in statuses)
print(len(statuses), failures)
print(f"{failures}/{len(statuses)}")

Expected output

4 1
1/4

The model defines failure as status at least 500 for four literals only. It does not establish Azure health or a production objective.

An alert needs an owner and a useful action

Define the condition, evaluation scope, action group or delivery route, owner, and response procedure. A notification configured in a portal is not proof that the responsible person receives it or can interpret the runbook. Choose thresholds from baseline traffic and user impact instead of a universal CPU or error percentage. Test notification routing with controlled synthetic evidence in a future authorized setup. Separate a transient dependency event from sustained user harm, and account for no-data conditions. Too many noisy alerts can hide the one signal that matters, while an unavailable telemetry pipeline can make a quiet dashboard falsely reassuring.

Useful diagnosis does not require secret payloads

Use stable event categories and bounded dimensions. Put correlation identifiers in controlled event context rather than unbounded metric labels, and avoid tokens, passwords, full request bodies, or private document contents. Limit access and retention according to data classification. Sampling and aggregation can change what a query can conclude, so state collection limits. This course performs no Azure query, agent installation, diagnostic configuration, alert delivery, or incident simulation against services. It validates local planning data and arithmetic only; actual collection, retention, notification, and recovery remain future verification responsibilities.

Common errors and fixes

Activity Log is called a complete application audit

Why it happens: Control-plane events are confused with every data/business operation.
How to fix it: Design application and supported data-plane evidence explicitly.
Prevent it next time: Map every required audit outcome to an actual collection source.

A no-data graph is assumed healthy

Why it happens: Collection failure and zero failures are conflated.
How to fix it: Check known-event arrival, scope, retention, and query filters.
Prevent it next time: Monitor the telemetry pipeline’s own failure conditions.

Private tokens appear in logs

Why it happens: Diagnostic convenience overrides data classification.
How to fix it: Redact secrets and retain only necessary safe context.
Prevent it next time: Review schemas and access before collecting telemetry.

Check your understanding

1. Does HTTP 202 prove a background document finished?

Show worked solution

No. It can acknowledge accepted work while processing remains pending or later fails. Define a durable operation identity and completion/error observations, then connect them with safe correlation context. The request metric and business completion metric should have their own populations and failure rules.

2. What should be investigated when a previously active log view becomes empty?