15.1 Azure Monitor Architecture, AMA & Data Collection Rules

15.1 Azure Monitor Architecture, AMA & Data Collection Rules

Modern DevOps practices rely fundamentally on continuous observability to detect failures before customers do, drive automated canary health gates, and maintain high system reliability. In Microsoft Azure, Azure Monitor serves as the central observability platform that ingests, aggregates, and analyzes telemetry from infrastructure, platforms, and application runtimes.

For the AZ-400 exam, candidates must master the telemetry collection architecture of Azure Monitor, differentiate between time-series metrics and structured log data, navigate the transition to the Azure Monitor Agent (AMA) and Data Collection Rules (DCRs), instrument applications via Application Insights (contrasting SDK versus codeless approaches), leverage specialized container and virtual machine insights, and configure diagnostic settings to route telemetry across enterprise storage and analytics destinations.

---

1. Azure Monitor Core Architecture: Metrics vs. Logs

Azure Monitor ingests telemetry from applications, operating systems, cloud resources, and subscription activity. At the core of the Azure Monitor data platform sit two distinct, complementary data stores: Metrics and Logs. Understanding their architectural differences is essential for designing resilient monitoring, alerting, and auto-scaling strategies.

                              [Telemetry Sources]
             (Applications, VMs, PaaS Services, Subscriptions, Arc)
                                       │
                   ┌───────────────────┴───────────────────┐
                   ▼                                       ▼
        [Azure Monitor Metrics]                 [Azure Monitor Logs]
        • Time-series numerical data            • Structured records & text
        • In-memory time-series store           • Log Analytics Workspace (Kusto engine)
        • Real-time, sub-minute latency         • Rich querying via KQL
        • 93-day standard retention             • 30 to 730 days (Archive to 12 years)
        • Fast alerts & autoscale triggers      • Deep troubleshooting & audits

Architectural Comparison

Key Exam Rule: When to Use Which

• Choose Metrics when you need sub-minute alerting, automated scaling triggers (e.g., scale out Virtual Machine Scale Sets when CPU > 75%), or lightweight real-time dashboarding.
• Choose Logs when you need complex correlation across services, regex parsing of error messages, cross-table joins (e.g., joining application exceptions with Kubernetes pod restarts), or long-term analytical queries using KQL.

---

2. Data Collection Evolution: Azure Monitor Agent (AMA) & Data Collection Rules (DCRs)

Historically, Azure relied on multiple disparate agents to collect operating system and infrastructure telemetry: the legacy Log Analytics Agent (also known as OMS or MMA - Microsoft Monitoring Agent), the Azure Diagnostic Extension (WAD for Windows, LAD for Linux), and the Telegraf agent.

[!IMPORTANT] The legacy Log Analytics agent (MMA/OMS) was officially deprecated and retired on August 31, 2024. For the AZ-400 exam, any architecture referencing MMA or OMS is obsolete. The only supported, modern standard is the Azure Monitor Agent (AMA) governed by Data Collection Rules (DCRs).

Azure Monitor Agent (AMA) Capabilities

The Azure Monitor Agent unifies OS-level telemetry collection into a single, secure, performant daemon supporting Windows and Linux across:

• Azure Virtual Machines and Virtual Machine Scale Sets (VMSS).
• Hybrid and Multicloud Servers connected through Azure Arc.
• Azure Kubernetes Service (AKS) nodes.

Key architectural improvements include:

1. Managed Identity Authentication: AMA uses system-assigned or user-assigned Managed Identities to authenticate securely with Azure Monitor, eliminating hardcoded workspace IDs and shared primary keys.
2. Multi-Homing: A single VM running AMA can stream logs and performance data to multiple Log Analytics workspaces across different subscriptions or tenants simultaneously.
3. Network Isolation: Operates seamlessly over Azure Private Link using Azure Monitor Private Link Scopes (AMPLS).

Data Collection Rules (DCRs) and Data Collection Endpoints (DCEs)

Data Collection Rules (DCRs) are cloud-native Azure Resource Manager (ARM) resources that decouple data collection logic from the host operating system. Instead of configuring agents locally via XML files or portal toggles, a DCR centrally defines:

• Data Sources: Which performance counters, Windows Event Logs (System, Application, Security), Linux syslog facilities, or custom log text files to gather.
• Stream Transformations (KQL Filtering at Ingestion): DCRs allow engineers to write KQL transformations that filter, mask, or enrich records before they are ingested into the workspace.
• Destinations: Where to send the collected streams—such as one or more Log Analytics Workspaces, Azure Monitor Metrics, or Event Hubs.

[Virtual Machine / Azure Arc Host]
  │  (Runs Azure Monitor Agent - AMA)
  ▼
[Data Collection Rule - DCR]
  │  1. Collect: Windows Security Events
  │  2. Transform: source | where EventID == 4625 (Drop successful 4624 logons!)
  ▼
[Log Analytics Workspace]  ──► [Cost Savings: 80% reduction in unneeded ingestion volume]

Ingestion-Time Filtering for Cost Optimization (Top Exam Scenario)

A classic AZ-400 challenge involves uncontrolled Log Analytics ingestion costs caused by high-volume Windows Security events. By default, collecting the Windows Security log ingests millions of informational Event ID 4624 (Successful Logon) events. With DCR stream transformations, DevOps engineers configure a KQL filter directly in the DCR:

{
  "properties": {
    "streamDeclarations": {
      "Custom-SecurityStream": {
        "columns": [
          { "name": "TimeGenerated", "type": "datetime" },
          { "name": "EventID", "type": "int" },
          { "name": "Account", "type": "string" },
          { "name": "Message", "type": "string" }
        ]
      }
    },
    "dataFlows": [
      {
        "streams": [ "Microsoft-SecurityEvent" ],
        "destinations": [ "la-workspace-prod" ],
        "transformKql": "source | where EventID == 4625",
        "outputStream": "Microsoft-SecurityEvent"
      }
    ]
  }
}

This ensures only failed logon attempts (Event ID 4625) are sent over the network and ingested, saving thousands of dollars in monthly log ingestion fees.

Data Collection Endpoints (DCEs)

A Data Collection Endpoint (DCE) is required when using AMA with Azure Private Link (private DNS zones) or when collecting custom log files from virtual machines. The DCE provides the dedicated HTTPS ingestion URL that AMA contacts to pull configuration and transmit data payloads.

# Azure CLI: Associate a Data Collection Rule with an Azure VM
az monitor data-collection rule association create \
  --name "vm-security-dcr-assoc" \
  --resource "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/vm-payment-01" \
  --rule-id "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.Insights/dataCollectionRules/dcr-security-hardened"