Concept Mapping — SCOM ↔ Azure Monitor
The Azure Local delivery-surface Rosetta Stone. Architectural concepts mapped between SCOM and Azure Monitor. Locked by ADR 0006 (entity alignment) and ADR 0007 (naming).
Azure Local baseline
The entity mapping on this page applies to Azure Local. Hyper-V SCOM mapping will follow its topology spike. A Hyper-V Azure Monitor column is added only if ADR 0023 records a go decision.
Top-level concepts
| Concept | SCOM | Azure Monitor Health Models |
|---|---|---|
| Container for the whole model | Distributed Application | Service Group + Health Model linked to it |
| Thing to be monitored | Class instance | Entity (Azure Resource Entity / Logical Entity) |
| Class definition / type | <ClassType> in MP XML | Entity type implied by ARM resource type or logical entity definition |
| How instances are found | Discovery (PowerShell / WMI / script) | ARM resource membership in the Service Group + Resource Graph queries |
| Hierarchy | Hosting relationships + reference relationships | Parent/child relationships in the entity graph |
| Health-bearing condition | Monitor (Unit / Aggregate / Dependency) | Signal + threshold on an entity |
| Numeric data collection | Performance Collection Rule | Metric / KQL query on a DCR-collected log |
| Event collection | Event Collection Rule | KQL query on Event table populated by AMA |
| Alerting | Alert generated by a Monitor or Rule | Alert Rule on the signal (separate from health state) |
| Customer tuning | Override (in companion override pack) | Bicep parameter (in tier .bicepparam file) |
| Maintenance window | Maintenance Mode | Manual Healthy health objective or impact override |
| Visualization | SCOM Health Explorer + SquaredUp Dashboard Server | Azure portal Health Model view + Workbooks + SquaredUp Cloud |
Entity / class mapping
Per ADR 0005 and ADR 0006, the Azure Local baseline maps equivalent entities between delivery surfaces.
| Logical entity | SCOM class | Azure Monitor entity type | ARM resource type (if applicable) |
|---|---|---|---|
| Cluster | AzureLocal.Cluster | Azure Resource Entity | Microsoft.AzureStackHCI/clusters |
| Node | AzureLocal.Node | Azure Resource Entity | Microsoft.HybridCompute/machines |
| Storage Pool | AzureLocal.StoragePool | Logical Entity (custom signals) | n/a — inferred from cluster |
| Volume | AzureLocal.Volume | Logical Entity | n/a |
| Storage Tier | AzureLocal.StorageTier | Logical Entity | n/a |
| Network Intent | AzureLocal.NetworkIntent | Logical Entity | n/a (inferred from MS-SDDC-Mgmt) |
| Storage Replica | AzureLocal.StorageReplica | Logical Entity | n/a |
| Update / LCM | AzureLocal.UpdateState | Logical Entity | partly ARM solutionUpdates |
| Arc Resource Bridge | AzureLocal.ResourceBridge | Azure Resource Entity | Microsoft.ResourceConnector/appliances |
| AKS Arc platform | AzureLocal.AKSArcPlatform | Azure Resource Entity | Microsoft.Kubernetes/connectedClusters |
| DCMA / Cloud Agent | AzureLocal.DCMA | Logical Entity | n/a |
| HCI registration | AzureLocal.HCIRegistration | derived from cluster ARM | n/a |
| Custom Location | AzureLocal.CustomLocation | Azure Resource Entity | Microsoft.ExtendedLocation/customLocations |
| Logical Network | AzureLocal.LogicalNetwork | Azure Resource Entity | Microsoft.AzureStackHCI/logicalNetworks |
| Managed Identity | AzureLocal.ManagedIdentity | Azure Resource Entity | Microsoft.ManagedIdentity/userAssignedIdentities (and system MI on cluster) |
| Deployment SPN | AzureLocal.DeploymentSPN | Logical Entity (Graph) | n/a (Microsoft Graph) |
| Key Vault | AzureLocal.KeyVault | Azure Resource Entity | Microsoft.KeyVault/vaults |
| Storage Account | AzureLocal.StorageAccount | Azure Resource Entity | Microsoft.Storage/storageAccounts |
| RBAC assignments | AzureLocal.RBAC | Logical Entity | n/a |
| Update Manager linkage | AzureLocal.UpdateMgrLinkage | Logical Entity | Microsoft.Maintenance/configurationAssignments |
| Data Collection Rule | AzureLocal.DCR | Azure Resource Entity | Microsoft.Insights/dataCollectionRules |
| Log Analytics Workspace | AzureLocal.Workspace | Azure Resource Entity | Microsoft.OperationalInsights/workspaces |
Health state mapping
| SCOM | Azure Monitor | Color | Generic state |
|---|---|---|---|
Success | Healthy | Green | Healthy |
Warning | Degraded | Yellow | Degraded |
Error | Unhealthy | Red | Critical |
Uninitialized | Unknown | Grey | Unknown |
Signal naming parity
Per ADR 0007, every threshold has a single logical name, with mechanical translation to each track's idiom:
| Logical name | SCOM override key | Azure Monitor Bicep param |
|---|---|---|
Volume.FreeSpace.WarnPercent | Volume.FreeSpace.WarnPercent | volumeFreeSpaceWarningThresholdPct |
Volume.FreeSpace.CritPercent | Volume.FreeSpace.CritPercent | volumeFreeSpaceCriticalThresholdPct |
Node.CPU.WarnPercent | Node.CPU.WarnPercent | nodeCpuWarningThresholdPct |
Node.CPU.CritPercent | Node.CPU.CritPercent | nodeCpuCriticalThresholdPct |
KeyVault.SecretExpiry.WarnDays | KeyVault.SecretExpiry.WarnDays | keyVaultSecretExpiryWarningDays |
The translation is mechanical:
- SCOM key uses dot-separated PascalCase verbatim from the logical name.
- Bicep param uses camelCase, expands
Pct→PctandDays→Days, prefixed by entity.
A round-trip linter will validate applicable Azure Local parity during implementation.
Rollup mapping
| SCOM | Azure Monitor |
|---|---|
Dependency Monitor with Worst Of algorithm | Child entity with Standard impact |
Dependency Monitor with Best Of algorithm | Child entity with custom impact rule |
| Dependency Monitor disabled (or maintenance mode) | Child entity with Suppressed impact |
| Aggregate Monitor (Availability/Performance/Configuration/Security) | Health Objective on the entity, scoped per dimension |
Alert mapping
See ADR 0009. Alerts are intentionally separate from health state in both Azure Local delivery surfaces.
| SCOM | Azure Monitor |
|---|---|
Monitor with Generate alert enabled | Alert rule on the underlying signal (metric / KQL) |
| Alert severity (Critical / Warning / Information) | Alert severity (0–4) → action group routing |
| Notification subscription | Action group |
| Alert auto-resolve when monitor returns to Healthy | Alert auto-resolve via metric/log condition |
Migration implications
Because the conceptual model is identical and naming is parity-locked, a customer running the SCOM MP today can migrate to the Azure Monitor track without re-learning what is monitored — only the surface differs. The Migration Guide will walk through this end-to-end after both Azure Local surfaces ship.