What is Observability — Azure Monitor & App Insights in Microsoft Azure?

8 / 24

Microsoft Azure

Observability — Azure Monitor & App Insights

Unify metrics, logs, and traces and query them with KQL to monitor and debug systems.

One platform, three signals, and one query language that ties them together.

A mission control room with one big console (Azure Monitor) showing every gauge and log, where operators write precise queries (KQL) to interrogate the data, and a dedicated flight-path tracker (Application Insights) follows each request through the system and lights up the component that is failing.

Key Concepts

    metrics  is something wrong?     numeric, cheap, fast
    logs     what exactly happened?  detailed, expensive at volume
    traces   where in the path?      one request across services

Everything lands in a Log Analytics workspace and is queried with KQL, which is genuinely worth learning:

    requests
    | where timestamp > ago(1h) and success == false
    | summarize count() by resultCode, bin(timestamp, 5m)
    | order by count_ desc

Application Insights is the APM layer. Instrument an app and you get request rates, dependency calls, exceptions, and distributed tracing with an application map showing which component is slow.

Sampling is the detail people miss. App Insights samples telemetry by default to control cost, so counts in the portal are estimates scaled back up. Fine for trends, misleading if you are chasing one specific failed request — and adaptive sampling can be tuned or disabled for a critical service.

Alert on symptoms, not causes. High CPU may be harmless; a rising failure rate or p95 latency is what a user feels. Alerts fire Action Groups — email, SMS, webhook, Logic App, or an automation runbook that remediates.

Percentiles over averages. An average hides the slow tail entirely, and the tail is where the unhappy users are.

Log in structured form so KQL can filter on fields rather than matching strings, and set a retention period — telemetry kept forever is a quiet, permanent cost. Basic and Auxiliary table plans exist for high-volume logs you rarely query.

Correlate the three. An operation id on every request ties a metric spike to the traces that were slow and then to the exact log lines, which is the whole point of having them in one workspace.

Workbooks build the shared dashboards, and Azure Monitor for containers and VMs add the infrastructure layer underneath the application view.

What the interviewer is probing.1. "What is KQL and where do you use it?" Probing: the query language. Stalls: "A query tool." Moves up: Kusto Query Language, used across Log Analytics for logs, metrics and traces in one workspace — the main skill for working with Azure telemetry.

2. "Your Application Insights counts look wrong. Why?" Probing: sampling, which people miss. Stalls: "The data is late." Moves up: adaptive sampling is on by default and scales estimates back up — fine for trends, misleading when chasing one specific request.

3. "What should trigger a page?" Probing: symptoms versus causes. Stalls: "High CPU." *Moves up:* rising failure rate or p95 latency — what the user feels; CPU may be perfectly healthy.

4. "How do you connect a metric spike to a specific failure?" Probing: correlation. Stalls: "Search the logs." Moves up: the operation id ties a request across metrics, traces and log lines, which is the point of one workspace.