ADR 0006 — Azure Monitor entity model alignment (mirrors SCOM 1:1)
- Status: Accepted
- Date: 2026-05-05
- Deciders: @AzureLocal/azurelocal-scom-mp-maintainers
Context
ADR 0005 defines the SCOM class graph. The Azure Monitor Health Models track has its own entity model — but if we don't make explicit choices about how the two relate, they will drift over time and the cross-track parity guarantee (ADR 0007) becomes impossible to maintain.
Azure Monitor Health Models entity types (Microsoft Learn — Health Models overview):
- Azure Resource Entity — bound to a single ARM resource ID; inherits Resource Health automatically; signals via metrics, KQL on logs/Activity Log
- Logical Entity — abstract; not bound to an ARM resource; signals via KQL or model expressions
- Group Entity — collection of other entities (used for the model root and for groupings like "all nodes")
Azure Monitor relationships are simpler than SCOM:
- Parent / child with an
impactsetting (Standard/Limited/Suppressed) - No hosting vs. containment vs. reference distinction — one relationship type, semantics configured by impact
The Service Group (Microsoft Learn — Azure Service Groups) acts as the membership boundary — only resources in the Service Group can be Azure Resource Entities in the model. So Service Group composition is itself an architectural decision.
Decision
The Azure Monitor entity model mirrors the SCOM class hierarchy 1:1, with three mechanical translation rules:
Rule 1 — entity type follows ARM resource availability
| If the entity… | Use Azure Monitor entity type |
|---|---|
| Maps to a single ARM resource | Azure Resource Entity (bound to the ARM ID) |
| Has no ARM resource (purely on-prem concept like Volume, NetworkIntent) | Logical Entity with KQL/DCMA-metric signals |
| Is a roll-up grouping (Deployment root, "all nodes") | Group Entity |
Rule 2 — relationships use Standard impact unless ADR 0003 says otherwise
ADR 0003 is the rollup policy. The mechanical translation:
| SCOM relationship | Azure Monitor impact |
|---|---|
| Hosting / containment + Worst-of dependency | Standard |
| Reference relationship | Standard (still rolls up — they're real parts of the deployment) |
| Documented exception (e.g., Storage Replica DR partner unreachable) | Suppressed |
Update.LastResult | Limited (max severity Warning) |
Rule 3 — Service Group membership = the entity inventory
The Azure Service Group for an Azure Local deployment must include exactly the L3 entities from ADR 0001:
Microsoft.AzureStackHCI/clusters(the cluster resource)Microsoft.HybridCompute/machines(each node)Microsoft.AzureStackHCI/logicalNetworksMicrosoft.ResourceConnector/appliances(Resource Bridge)Microsoft.ExtendedLocation/customLocationsMicrosoft.KeyVault/vaults(the deployment Key Vault)Microsoft.Storage/storageAccounts(the deployment Storage Account)Microsoft.ManagedIdentity/userAssignedIdentitiesMicrosoft.Insights/dataCollectionRulesMicrosoft.OperationalInsights/workspaces(linked LAW)
Logical entities (Volume, NetworkIntent, StoragePool, etc.) are added to the model but not to the Service Group (Service Groups can only contain ARM resources).
Entity-level signal sources
Per ADR 0002:
| Entity layer | First signal | Second signal | Notes |
|---|---|---|---|
| L3 Azure Resource Entity | Resource Health | Activity Log adverse events | Free; both auto-emit |
| L1 Logical Entity | DCMA metric (AzureStackHCI/clusters namespace) | KQL on Event from AMA | DCMA preferred for time-series; KQL for state |
| Cross-resource (e.g., RBAC drift) | Resource Graph KQL | n/a | Run on a schedule via DCR or alert rule |
Health Objectives
Each entity has up to four Health Objectives, matching the four health dimensions locked by the Health Model:
- Availability
- Performance
- Configuration
- Security (L3 only)
Each objective has its own signal set and rolls up via worst-of within the entity.
Consequences
- Positive: 1:1 alignment makes cross-track parity tractable. Every SCOM class has an Azure Monitor entity counterpart with the same signals (translated per ADR 0007).
- Positive: Bound Azure Resource Entities inherit Resource Health for free — the baseline signal on every L3 entity is built in.
- Positive: Service Group composition is explicit and enforceable — a Bicep template can stamp out the Service Group with the exact required members.
- Positive: Logical Entities for L1 mean we can model on-prem-only concepts (Volume, StoragePool, NetIntent) cleanly, without having to invent fake ARM resources.
- Negative: Logical Entities don't inherit Resource Health — every signal on them is custom KQL or DCMA. More authoring cost, but unavoidable for on-prem-only entities.
- Negative: Service Group membership has to be maintained — adding a new resource to a deployment requires adding it to the Service Group too. Mitigated by the Bicep module (ADR 0008) which always emits the full set.
- Affected: Phase 4 Azure Monitor authoring derives every entity, every relationship, and the Service Group definition from this ADR.
Alternatives considered
- Don't mirror SCOM — design Azure Monitor model independently — rejected: defeats the cross-track parity story; doubles authoring cost; creates two different mental models.
- Make every L1 entity a fake ARM resource — rejected: not supported by ARM and pollutes the resource graph.
- One mega-Logical Entity for the whole cluster — rejected: collapses the rollup signal; operators can't drill into a specific volume's health.
References
- ADR 0001 — Scope & topology
- ADR 0002 — Primary signal source
- ADR 0003 — Health rollup policy
- ADR 0005 — SCOM class hierarchy
- ADR 0007 — Naming convention
- Azure Monitor Health Models — overview
- Azure Service Groups — overview
- Resource Health — list of supported resource types
- Azure Local — monitoring overview