Microsoft Azure
Intermediate 15 min read Microsoft Azure

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.

Azure MonitorApplication InsightsLog AnalyticsmetricsalertsDefender for CloudEntra IDAzure ADsecurityobservabilitykey vault
Introduction

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.

Motivation

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.
Think about it

Mental model

Imagine

A building with an operations room and a security team

Think of

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.

Mechanics

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.

Resource emits telemetry
Azure Monitor collects
Log Analytics workspace
Application Insights
Alerts fire on thresholds
Defender scores the posture
Reference

Key commands

az monitor metrics list --resource <vm-id> --metric "Percentage CPU" --interval PT1M

List 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-dev

Create an Application Insights resource.

az security assessment list --resource-group rg-dev

List Defender for Cloud recommendations.

az ad sp list --query "[?appDisplayName=='devops-app'].[appId,id]"

List service principals (Entra ID applications).

Hands-on

Examples

Query metrics and logs with Azure Monitor

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.

Real world

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.
Guidelines

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.
Watch out

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.
Root cause analysis

Common issues

Error
No logs appear in Log Analytics for a resource
Root cause

Diagnostic settings are not configured to stream that resource's logs to the workspace.

Fix

Create a diagnostic setting that sends audit, resource and platform logs to the workspace, then allow up to a few minutes to ingest.

Error
An alert fires but the on-call cannot see why
Root cause

The alert rule has no runbook, dashboard link or grouped data in its notification.

Fix

Add an action group with a runbook or workbook link and include the query or metric context in the alert payload.

Error
Application Insights shows no request telemetry
Root cause

The app is not instrumented, or the connection string is missing in the environment.

Fix

Install the SDK/agent, set the Application Insights connection string via App Settings, and redeploy before retesting.

When things break

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.
Interviews

Interview checkpoint

Practice

Hands-on lab

Simulate Metrics, Alert Thresholds and an Action Group
20 min · intermediate
In progress
Objectives
  • 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

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which Azure Monitor component stores log data queryable with KQL?

2

Resources stream logs into Log Analytics by default without configuration.

3

A web app is slow but the CPU alerts never fire. Where should you look first?

Quick reference

Cheat sheet

Observe
Azure MonitorUnified metrics + logs + alerts
Log AnalyticsKQL queries over collected logs
Application InsightsApp telemetry, traces, exceptions
Action groupWho to page and how
Protect
Defender for CloudSecure score + recommendations
Entra IDUsers, groups, service principals
RBACRole-based authorization
Key VaultSecrets, keys, certificates
Managed identityPasswordless workload identity
Go deeper

Official documentation