Concept Mapping — SCOM ↔ Azure Monitor¶
The dual-track Rosetta Stone. Every architectural concept in this project, mapped 1:1 across the two delivery tracks. Locked by ADR 0006 (entity alignment) and ADR 0007 (naming).
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, entities map 1:1 across tracks.
| 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 → Pct and Days → Days, prefixed by entity.
A round-trip linter validates parity at PR time (planned for Phase 3).
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 tracks.
| 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 (Phase 5) walks through this end-to-end.