Logging, Monitoring, and Operations

Logs and alerts are not something you add after the first incident. They are part of the platform’s first day. If monitoring arrives late, the platform’s earliest and most formative changes happen with no record and no alerting — exactly when you most want both.

Purpose

This page defines the operational monitoring baseline for the platform: logs, metrics, Activity Logs, diagnostic settings, alerts, action groups, workbooks, and reporting.

Design Reasoning

A practical starting point is one central Log Analytics workspace in the management subscription. Microsoft’s guidance is to start with a single workspace and split only when a clear requirement exists — data residency, access isolation, cost separation, or retention differences. A useful rule of thumb: one workspace per Microsoft Entra tenant, plus a separate workspace per region only where data-residency rules demand it.

Two facts shape the rest of the design:

• Azure does not collect resource logs automatically. Diagnostic settings must be configured per supported resource type — or, far better, deployed at scale with Azure Policy (DeployIfNotExists).
• The Activity Log is retained for 90 days and then deleted. For longer retention and cross-subscription analysis, export it to the workspace with a diagnostic setting (it lands in the AzureActivity table).

Architecture Decision Record

Tradeoff: A single workspace concentrates cost and access in one place. For most small-to-medium organizations that concentration is a feature — one place to query, one place to govern — and you split only when a concrete requirement forces it.

Recommended Configuration

A single action group can be reused across many alert rules, and a single alert rule can reference up to five action groups — so define a few well-named action groups (for example, one for high-severity platform alerts) and reuse them.

Example Implementation

Create the central workspace in the management subscription:

1
az group create \
2
  --name rg-platform-monitoring-prod-sec-001 \
3
  --location switzerlandnorth
4

5
az monitor log-analytics workspace create \
6
  --resource-group rg-platform-monitoring-prod-sec-001 \
7
  --workspace-name log-platform-prod-sec-001 \
8
  --location switzerlandnorth

Failed control-plane operations in the last 24 hours:

1
AzureActivity
2
| where TimeGenerated > ago(24h)
3
| where ActivityStatusValue in ("Failure", "Failed")
4
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, SubscriptionId
5
| order by TimeGenerated desc

Delete operations across the estate in the last seven days:

1
AzureActivity
2
| where TimeGenerated > ago(7d)
3
| where OperationNameValue contains "delete"
4
| project TimeGenerated, Caller, OperationNameValue, _ResourceId
5
| order by TimeGenerated desc

Validation Steps

1
# Confirm the workspace exists
2
az monitor log-analytics workspace show \
3
  --resource-group rg-platform-monitoring-prod-sec-001 \
4
  --workspace-name log-platform-prod-sec-001
5

6
# Confirm a resource is forwarding logs
7
az monitor diagnostic-settings list --resource <resource-id>
8

9
# Confirm centralized action groups exist
10
az monitor action-group list \
11
  --resource-group rg-platform-monitoring-prod-sec-001 \
12
  --output table

Common Mistakes

• Creating one workspace per team too early, before a real requirement justifies the split.
• Not exporting Activity Logs, then losing control-plane history after 90 days.
• Not enabling diagnostic settings for critical resources, so resource logs are simply absent.
• Alerts without central action groups, or alerts with no owner, so notifications go nowhere.
• Keeping logs with no retention or cost plan, which produces a surprise bill.
• Not using workbooks for platform-level visibility.

References

• Design a Log Analytics workspace architecture
• Diagnostic settings in Azure Monitor
• Create diagnostic settings at scale using Azure Policy
• Azure Activity Log
• Create and manage action groups
• Best practices for Azure Monitor alerts