Azure Monitor

Azure Monitor Skill

Manage and analyze Azure Monitor resources using az monitor commands.

Discovery-First Rule

ALWAYS discover before acting. Never assume workspace names, alert rule names, metric names, or action group names.

# Discover Log Analytics workspaces
az monitor log-analytics workspace list --output json \
  --query "[].{name:name, rg:resourceGroup, sku:sku.name, retentionDays:retentionInDays, dailyCapGB:workspaceCapping.dailyQuotaGb}"

# Discover metric alert rules
az monitor metrics alert list --output json \
  --query "[].{name:name, rg:resourceGroup, severity:severity, enabled:enabled, targetResource:scopes[0]}"

Parallel Execution Requirement

ALL independent operations MUST run in parallel using background jobs (&) and wait.

for ws in $(echo "$workspaces" | jq -c '.[]'); do
  {
    name=$(echo "$ws" | jq -r '.name')
    rg=$(echo "$ws" | jq -r '.rg')
    az monitor log-analytics workspace show --workspace-name "$name" --resource-group "$rg" --output json
  } &
done
wait

Helper Functions

# Run a Log Analytics query
run_log_query() {
  local workspace="$1" query="$2" timespan="${3:-PT1H}"
  az monitor log-analytics query --workspace "$workspace" --analytics-query "$query" --timespan "$timespan" --output json
}

# List available metrics for a resource
list_metrics() {
  local resource_id="$1"
  az monitor metrics list-definitions --resource "$resource_id" --output json \
    --query "[].{name:name.value, displayName:name.localizedValue, unit:unit, aggregations:supportedAggregationTypes}"
}

# Get metric values
get_metrics() {
  local resource_id="$1" metrics="$2" interval="${3:-PT1H}" aggregation="${4:-Average}"
  az monitor metrics list --resource "$resource_id" --metric $metrics \
    --interval "$interval" --aggregation $aggregation --output json
}

# List action groups
list_action_groups() {
  local rg="$1"
  az monitor action-group list --resource-group "$rg" --output json \
    --query "[].{name:name, enabled:enabled, emailReceivers:emailReceivers[].name, smsReceivers:smsReceivers[].name, webhookReceivers:webhookReceivers[].name}"
}

Common Operations

1. Workspace Overview and Usage

workspaces=$(az monitor log-analytics workspace list --output json --query "[].{name:name, rg:resourceGroup, id:customerId}")
for ws in $(echo "$workspaces" | jq -c '.[]'); do
  {
    name=$(echo "$ws" | jq -r '.name')
    rg=$(echo "$ws" | jq -r '.rg')
    ws_id=$(echo "$ws" | jq -r '.id')
    az monitor log-analytics workspace show --workspace-name "$name" --resource-group "$rg" --output json \
      --query "{name:name, sku:sku.name, retentionDays:retentionInDays, dailyCap:workspaceCapping.dailyQuotaGb, ingestionStatus:workspaceCapping.quotaNextResetTime}"
    # Check data volume
    run_log_query "$ws_id" "Usage | where TimeGenerated > ago(24h) | summarize DataGB=sum(Quantity)/1024 by DataType | sort by DataGB desc | take 10" "P1D"
  } &
done
wait

2. Alert Rules Audit

# Metric alerts
az monitor metrics alert list --output json \
  --query "[].{name:name, severity:severity, enabled:enabled, condition:criteria.allOf[0].{metric:metricName,operator:operator,threshold:threshold}, actions:actions[].actionGroupId}"

# Log alerts (scheduled query rules)
az monitor scheduled-query list --output json \
  --query "[].{name:name, severity:severity, enabled:enabled, evaluationFrequency:evaluationFrequency, windowSize:windowSize}"

# Activity log alerts
az monitor activity-log alert list --output json \
  --query "[].{name:name, enabled:enabled, scopes:scopes, condition:condition}"

3. Log Analytics Queries

# Recent errors across all tables
run_log_query "$WORKSPACE_ID" "union withsource=TableName * | where TimeGenerated > ago(1h) | where Level == 'Error' or severityLevel >= 3 | summarize count() by TableName | sort by count_ desc"

# Heartbeat check for monitored VMs
run_log_query "$WORKSPACE_ID" "Heartbeat | summarize LastHeartbeat=max(TimeGenerated) by Computer | where LastHeartbeat < ago(15m)"

# Ingestion latency
run_log_query "$WORKSPACE_ID" "Heartbeat | where TimeGenerated > ago(1h) | extend IngestionDelay=ingestion_time()-TimeGenerated | summarize avg(IngestionDelay), max(IngestionDelay) by bin(TimeGenerated, 5m)"

4. Diagnostic Settings Audit

# Check diagnostic settings for a resource
az monitor diagnostic-settings list --resource "$RESOURCE_ID" --output json \
  --query "[].{name:name, workspace:workspaceId, storageAccount:storageAccountId, eventHub:eventHubAuthorizationRuleId, logs:logs[].{category:category, enabled:enabled, retention:retentionPolicy.days}, metrics:metrics[].{category:category, enabled:enabled}}"

5. Action Group Configuration

az monitor action-group list --output json \
  --query "[].{name:name, rg:resourceGroup, enabled:enabled, email:emailReceivers[].{name:name,address:emailAddress}, sms:smsReceivers[].{name:name,phone:phoneNumber}, webhook:webhookReceivers[].{name:name,uri:serviceUri}, logicApp:logicAppReceivers[].{name:name}, azureFunction:azureFunctionReceivers[].{name:name}}"

Output Format

Present results as a structured report:

Azure Monitor Report
════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]

Target ≤50 lines of output. Use tables for multi-resource comparisons.

Anti-Hallucination Rules

1. NEVER assume resource names — always discover via CLI/API in Phase 1 before referencing in Phase 2.
2. NEVER fabricate metric names or dimensions — verify against the service documentation or --help output.
3. NEVER mix CLI commands between service versions — confirm which version/API you are targeting.
4. ALWAYS use the discovery → verify → analyze chain — every resource referenced must have been discovered first.
5. ALWAYS handle empty results gracefully — an empty response is valid data, not an error to retry.

Counter-Rationalizations

Common Pitfalls

1. Metric namespaces: Different resource types expose different metrics. Always use list-definitions to discover available metrics before querying.
2. Log Analytics timespan format: Use ISO 8601 duration format (e.g., PT1H, P1D, P7D), not date ranges.
3. Daily cap resets: When daily ingestion cap is hit, data is dropped until the next reset time. Check quotaNextResetTime.
4. Alert action groups: An alert without action groups will fire but nobody gets notified. Always verify action group linkage.
5. KQL vs SQL: Log Analytics uses Kusto Query Language (KQL), not SQL. Common mistakes include using SELECT instead of project and GROUP BY instead of summarize.