Azure Monitoring & Security
Azure Monitor collects metrics, logs and traces from every Azure resource; Application Insights adds application-level telemetry and diagnostics. Microsoft Defender for Cloud and Microsoft Entra ID (formerly Azure AD) provide security posture, identity and access control. Learn how the pieces fit together to observe and protect a workload.
What is this?
Azure Monitor is the unified observability plane: it ingests platform metrics and logs, and sends them to Log Analytics workspaces for querying and alerting. Application Insights instruments application code for requests, dependencies, exceptions and distributed traces. On the security side, Microsoft Defender for Cloud assesses your environment against best-practice recommendations, and Microsoft Entra ID is the identity and access management layer that governs who can do what, backed by Key Vault for secret storage.
Why do you need it?
- You cannot run a platform blind — Monitor ties metrics and logs to one query and alert surface.
- Application Insights shows the app's health from the inside: latency, dependencies and trace flows.
- Defender for Cloud turns security into a score and a fix list instead of folklore.
- Entra ID plus RBAC is the gate for every human and workload identity on the platform.
- Every DevOps interview expects you to describe monitoring and security as core responsibilities.
Mental model
A building with an operations room and a security team
Azure Monitor and Defender for Cloud
Azure Monitor is the operations room: dashboards of gauges (metrics), a logbook of every event (Log Analytics), and pagers wired to thresholds (alerts). Application Insights is a health tracker on each employee's badge, recording every task and delay (requests and dependencies). Defender for Cloud is the security auditor who walks the floors ticking a checklist and issuing a score, while Entra ID is the guard desk checking badges (identity) before anyone steps on the elevator.
How it works
- Every Azure resource emits platform metrics and activity logs automatically; Azure Monitor collects them.
- Diagnostic settings stream resource logs and metrics into a Log Analytics workspace for KQL queries and alerts.
- Application Insights instruments your app — requests, dependencies, exceptions, traces — and correlates them in distributed traces.
- Defender for Cloud continuously assesses resources against security recommendations and computes a secure score.
- Entra ID issues and validates identities — users, groups, service principals, managed identities — that RBAC authorizes against roles.
Observability and security layers around a workload.
Key commands
az monitor metrics list --resource <vm-id> --metric "Percentage CPU" --interval PT1MList a metric's time series for a resource.
az monitor log-analytics query --workspace <workspace-id> --analytics-query "Heartbeat | where TimeGenerated > ago(1h) | count"Run a KQL query against a Log Analytics workspace.
az monitor alert create --name high-cpu --resource-group rg-dev --condition "Percentage CPU > 90" --description "CPU over 90%"Create a metric alert rule.
az monitor app-insights component create --app app-insights --location eastus --resource-group rg-devCreate an Application Insights resource.
az security assessment list --resource-group rg-devList Defender for Cloud recommendations.
az ad sp list --query "[?appDisplayName=='devops-app'].[appId,id]"List service principals (Entra ID applications).
Examples
Query metrics and logs with Azure Monitor
$ az monitor metrics list --resource <vm-id> --metric Percentage CPU \ --interval PT1M[ { "name": { "value": "Percentage CPU" }, "timeseries": [ { "data": [ { "average": 42.3 } ] } ] }] $ az monitor log-analytics query --workspace <workspace-id> \ --analytics-query "Heartbeat | where TimeGenerated > ago(1h) | count"{ "tables": [ { "name": "PrimaryResult", "rows": [ [ 12 ] ] } ]}The metrics call returns a time series for Percentage CPU. The log query asks the Log Analytics workspace for the count of Heartbeat records in the last hour — a basic health signal. Both plug into dashboards and alert rules, so monitoring is data first, dashboards second.
In production
- Stream platform logs for every critical resource into one Log Analytics workspace, then build alerts and dashboards on it.
- Instrument applications with Application Insights so requests, dependencies and exceptions surface in the same console.
- Act on Defender for Cloud recommendations by priority and track the secure score over time.
- Use managed identities for workload auth and keep secrets in Key Vault with rotation.
- Alert on symptoms (availability, latency, error rate) rather than on root-cause guesses like raw CPU.
Best practices
- Define SLOs first, then derive monitoring — you alert on things that threaten the SLO, not on every spike.
- Use action groups so alerts page the right on-call with runbook links.
- Set retention and archiving on Log Analytics to control cost; not every log must live forever.
- Apply least-privilege RBAC everywhere — humans, services and monitoring access included.
- Test alert rules by firing them in staging so 'the alert that never fires' is caught early.
Common mistakes
- Collecting every log at full retention and watching the Log Analytics bill explode.
- Writing alerts for the metric everyone glances at but no one acts on, so real issues drown.
- Storing secrets and connection strings in app settings instead of Key Vault.
- Giving the same role to every employee and service principal, including unnecessary write permissions.
- Fixing Defender recommendations once and never re-scanning after the next release.
Common issues
No logs appear in Log Analytics for a resourceDiagnostic settings are not configured to stream that resource's logs to the workspace.
Create a diagnostic setting that sends audit, resource and platform logs to the workspace, then allow up to a few minutes to ingest.
An alert fires but the on-call cannot see whyThe alert rule has no runbook, dashboard link or grouped data in its notification.
Add an action group with a runbook or workbook link and include the query or metric context in the alert payload.
Application Insights shows no request telemetryThe app is not instrumented, or the connection string is missing in the environment.
Install the SDK/agent, set the Application Insights connection string via App Settings, and redeploy before retesting.
Debugging tips
- Trace a slow page by opening its Application Insights distributed trace and following the dependency chain.
- Check the activity log for 'who changed this and when' before debugging the effect.
- Query KQL with a narrow time window first, then widen — a good query on bad data wastes hours.
- Verify diagnostic settings are on: resources emit nothing to Log Analytics until you stream it.
- Compare the secure score before and after a change to measure whether security actually improved.
Interview checkpoint
Hands-on lab
- Generate and record metric samples
- Detect a breach of a 90% threshold
- Route the alert to a fake on-call page
- Simulate a remediation script running
Simulate Metrics, Alert Thresholds and an Action Group
20 min · intermediate
Quick quiz
Which Azure Monitor component stores log data queryable with KQL?
Resources stream logs into Log Analytics by default without configuration.
A web app is slow but the CPU alerts never fire. Where should you look first?
Cheat sheet
Azure MonitorUnified metrics + logs + alertsLog AnalyticsKQL queries over collected logsApplication InsightsApp telemetry, traces, exceptionsAction groupWho to page and howDefender for CloudSecure score + recommendationsEntra IDUsers, groups, service principalsRBACRole-based authorizationKey VaultSecrets, keys, certificatesManaged identityPasswordless workload identity