Skip to content

Scope & Topology¶

Locked by ADR 0001. This page is the reader-friendly view of that decision.

What we monitor¶

Azure Local infrastructure only — every component that is deployed as part of an Azure Local deployment. Three layers, ~25 entities. Workloads (VMs, AKS pods, applications) are explicitly out of scope and tracked as future companion MPs in the Roadmap.

Three-layer entity model¶

flowchart TD
    subgraph L3["Layer 3 — Azure-side"]
        HCI[HCI Cluster Resource]
        ARC[Arc-enabled Servers]
        CL[Custom Location]
        LN[Logical Networks]
        MI[Managed Identities]
        SPN[Deployment SPN]
        KV[Key Vault]
        SA[Storage Account]
        RBAC[RBAC Assignments]
        UM[Update Manager]
        DCR[Data Collection Rules]
        LAW[Log Analytics Workspace]
        RH[Resource Health / Activity Log]
    end
    subgraph L2["Layer 2 — Cluster-resident platform"]
        ARB[Arc Resource Bridge / MOC]
        AKS[AKS Arc platform]
        DCMA[Cloud Agent / DCMA]
        ARCAGENT["Arc Agent
(per node — Tier A)"]
        REG[HCI Registration]
    end
    subgraph L1["Layer 1 — On-prem"]
        CLU[Cluster]
        N[Node]
        SP[Storage Pool]
        PD[Physical Disk]
        VOL[Volume / CSV]
        ST[Storage Tier]
        NI[Network Intent]
        NA[Network Adapter]
        SR[Storage Replica]
        UP[Update / LCM]
    end
    L3 -->|deployment provisions| L2
    L2 -->|runs on| L1
    PD -->|rolls up to| SP
    NA -->|rolls up to| NI

Layer 1 — On-prem (the cluster box)¶

Entity	SCOM class	Base class	Purpose	Source
Cluster	`AzureLocal.Cluster`	`Microsoft.Windows.LocalApplication`	The Azure Local cluster (S2D + Failover Clustering)	`Get-Cluster` / `Get-ClusterResource`
Node	`AzureLocal.Node`	`Microsoft.Windows.LocalApplication`	Each cluster member node	`Get-ClusterNode` / WMI
Storage Pool	`AzureLocal.StoragePool`	`Microsoft.Windows.ApplicationComponent`	The Storage Spaces Direct pool	`Get-StoragePool`
Volume (CSV)	`AzureLocal.Volume`	`Microsoft.Windows.ApplicationComponent`	Each cluster shared volume	`Get-Volume` / `Get-ClusterSharedVolume`
Storage Tier	`AzureLocal.StorageTier`	`Microsoft.Windows.ApplicationComponent`	Pool's cache + capacity tiers	`Get-StorageTier`
Physical Disk	`AzureLocal.PhysicalDisk`	`Microsoft.Windows.ApplicationComponent`	Each physical disk in the S2D pool — health, media type, usage	`Get-PhysicalDisk`
Network Intent	`AzureLocal.NetworkIntent`	`Microsoft.Windows.ApplicationComponent`	Each named Network ATC intent (Mgmt / Compute / Storage)	`Get-NetIntent` / `Get-NetIntentStatus`
Network Adapter	`AzureLocal.NetworkAdapter`	`Microsoft.Windows.ApplicationComponent`	Each physical NIC bound to a Network Intent — link speed, RDMA, PFC/ETS	`Get-NetAdapter` / `Get-NetAdapterRdma`
Storage Replica	`AzureLocal.StorageReplica`	`Microsoft.Windows.ApplicationComponent`	Replication relationship (if configured)	`Get-SRPartnership`
LCM State	`AzureLocal.LCMState`	`Microsoft.Windows.ApplicationComponent`	Solution-level update posture	`Get-SolutionUpdate` (Azure Local LCM)

Granularity note (updated): AzureLocal.PhysicalDisk is a hosted class beneath AzureLocal.StoragePool. A disk's health state is its own SCOM object, but it rolls up to the pool via an aggregated health roll-up monitor. Similarly AzureLocal.NetworkAdapter is hosted beneath AzureLocal.NetworkIntent; individual NIC failures propagate to the parent intent. All base class choices follow Brian Wren Module 7 — see ADR 0005 for the full inheritance tree.

Layer 2 — Cluster-resident platform services¶

Entity	SCOM class	Base class	Purpose	Source
Arc Resource Bridge / MOC	`AzureLocal.ArcResourceBridge`	`Microsoft.Windows.LocalApplication`	The Resource Bridge VM and its MOC components	`az arcappliance` / Resource Health
AKS Arc platform	`AzureLocal.AKSArcPlatform`	`Microsoft.Windows.ApplicationComponent`	AKS platform only (host pool, control plane reachability)	AKS extension status
Cloud Agent / DCMA	`AzureLocal.DCMA`	`Microsoft.Windows.ApplicationComponent`	Microsoft-supplied management agents — locally observable	Service state + registry + last heartbeat
Arc agent (per node)	`AzureLocal.Node` (attribute group)	(extends Node)	Arc Connected Machine Agent services + extension health — locally observable, no ARM required (see ADR 0011 Tier A)	`Get-Service HIMDS`, registry, event log
HCI registration state	`AzureLocal.HCIRegistration`	`Microsoft.Windows.ApplicationComponent`	Registration / billing / license tier	ARM resource state + local registry

ADR 0011 Tier A signals: Arc agent connectivity and extension health signals are collected on AzureLocal.Node (not a separate class) using agent-local data sources. See signal-catalog.md — Arc agent locally observable.

Layer 3 — Azure-side infrastructure¶

Entity	Purpose	Source
HCI Cluster resource	`Microsoft.AzureStackHCI/clusters`	ARM / Resource Graph
Arc-enabled Server (per node)	`Microsoft.HybridCompute/machines`	ARM + Connected Machine Agent
Custom Location	The Custom Location Azure resource	ARM
Logical Networks	`Microsoft.AzureStackHCI/logicalNetworks`	ARM
Managed Identities	System- + user-assigned MIs used by the deployment	ARM + Microsoft Graph
Deployment SPN	The SPN performing deployment / ongoing operations	Microsoft Graph
Key Vault	Secrets, access policies, expiry	ARM + Resource Health
Storage Account	Account, ACLs, redundancy	ARM + Resource Health
RBAC / role assignments	Required role assignments on cluster identity, SPN, MI	ARM Authorization
Update Manager linkage	Azure Update Manager linkage for the cluster	ARM
Data Collection Rules	DCRs associated with the cluster	ARM
Log Analytics Workspace linkage	Workspace reachability + ingestion	ARM + KQL `Heartbeat`
Resource Health / Activity Log	Per-resource health stream	Activity Log stream

Total: ~27 entities across 3 layers (10 L1, 5 L2, 13 L3 — up from the original ~25 with the addition of AzureLocal.PhysicalDisk, AzureLocal.NetworkAdapter, and the Arc agent Tier A group).

Out of scope (deferred)¶

These are tracked in the Roadmap as future companion MPs that take a dependency on this health model:

Guest OS health inside HCI VMs
Application services running inside VMs
AKS Arc workload pods, deployments, ingress
SQL MI / AVD / other workloads
Customer applications and their dependencies

How tracks consume this scope¶

Track	Implementation
SCOM MP	One SCOM class per entity. L1+L2 discovered via PowerShell Discovery on each cluster node. L3 discovered via ARM/Resource Graph from a designated management server. See ADR 0004 and ADR 0005.
Azure Monitor Health Model	One model entity per entity. L1+L2 surfaced through HCI Insights + DCMA metrics + Resource Health on `AzureStackHCI/clusters`. L3 surfaced through Resource Health + Activity Log + Resource Graph signals. See ADR 0006.

References¶