Azure Local Distributed Application design
The Azure Local SCOM product ships its own Distributed Application. It does not reference the Hyper-V MP or any shared runtime library.
The root class is HybridSolutionsCloud.AzureLocal.Service, as accepted in ADR 0034. It extends Microsoft.SystemCenter.Service and represents one monitored Azure Local deployment. Its purpose is to answer one operator question: Is this Azure Local deployment healthy?
Service model
| DA branch | Membership | Rollup intent |
|---|---|---|
| Compute | Cluster service, node membership, quorum, CPU, and memory | Compute and cluster-coordination health |
| Storage | Health Service faults, pools, volumes/CSVs, and physical disks | Storage availability, configuration, capacity, and root-cause health |
| Network | Network ATC intent status | Host-network intent convergence and configuration health |
| Azure integration | Local registration state and locally installed Arc/MOC platform services | The node-side Azure integration boundary; Azure resource health remains outside this MP |
| Lifecycle | Locally observable solution-update state | Readiness and active-update health |
| Monitoring pipeline | SCOM agents, management-server probes, discovery freshness, and required collection paths from ADR 0018 | Independent pipeline health so stale green infrastructure cannot hide failed monitoring |
The DA instance and component membership are authored in Management Pack XML and populated through typed discoveries and stable relationship keys. Customers do not have to maintain membership in the SCOM Distributed Application Designer.
Health propagation
The DA organizes health; it does not replace entity monitoring.
| Layer | Responsibility |
|---|---|
| Unit monitors | Establish health for an Azure Local entity or signal |
| Aggregate monitors | Roll Availability, Configuration, Performance, and applicable Security state within an entity |
| Dependency monitors | Propagate health through discovered platform relationships and into each DA component group |
| DA root | Presents the deployment-level service state across the component groups |
ADR 0003 governs worst-state defaults and approved exceptions. ADR 0018 requires the monitoring-pipeline branch to participate directly at the root. Unknown, stale-data, maintenance-mode, and recovery behavior must be validated rather than allowed to resolve silently to Healthy.
Required product artifacts
- DA root and six component-group class definitions in the Azure Local Library MP;
- dynamic relationship and membership discoveries;
- aggregate and dependency monitors with upgrade-safe overrides where supported;
- Health Explorer, diagram, state, alert, and task views scoped to the deployment;
- optional report and service-level objective targeting for availability and selected performance rules;
- optional SquaredUp Dashboard Server views that target the Azure Local DA; and
- import, population, fault, recovery, upgrade, coexistence, and removal tests.
The health and alert architecture is the current visual and behavioral reference. The DA, component relationships, domain aggregates, and dependency monitors are authored in the functional development baseline; SCOM lab validation remains outstanding.
Boundaries
- The DA monitors Azure Local infrastructure, not guest operating systems or applications.
- A deployment failure does not roll into a Hyper-V DA.
- A combined Azure Local and Hyper-V estate view requires a future optional integration MP.
- DA membership and rollup changes are public behavior and follow the product's versioning and upgrade contract.