Reliability in Azure Monitor health models (preview)

Azure Monitor health models is a state-based monitoring capability. It represents Azure resources and logical workload components as entities, evaluates their monitoring signals, and rolls health up through the relationships between them. Use current and historical health to identify unhealthy components and understand how their health affects the overall workload. You can also create health-based alerts that integrate with Azure Monitor action groups.

When you use Azure, reliability is a shared responsibility. Microsoft provides a range of capabilities to support resiliency and recovery. You're responsible for understanding how those capabilities work within all of the services you use, and selecting the capabilities you need to meet your business objectives and uptime goals.

This article describes the reliability architecture of Azure Monitor health models and how the service responds to transient faults, availability zone failures, region-wide failures, and service maintenance. It explains how the management, evaluation, retrieval, and alerting paths can fail and recover independently. It also describes backup and restore, including how recovery differs for model configuration, current health, health history, telemetry, and alerts, and highlights key information about the service-level agreement (SLA).

Production deployment recommendations for reliability

For production workloads, we recommend that you:

Reliability architecture overview

This section describes some of the important aspects of how the service works that are most relevant from a reliability perspective. The section introduces the logical architecture, which includes some of the resources and features that you deploy and use. It also discusses the physical architecture, which provides details on how the service works under the covers.

Logical architecture

A health model is an Azure resource. It contains a root entity and can include more entities, relationships, signals, discovery rules, and authentication settings. The model uses this configuration to evaluate the health of workload components, roll health up through their relationships, and show current and historical health.

You work with the service through several paths, each with its own reliability characteristics:

• Management and configuration: The management path creates the model and manages its entities, relationships, signals, discovery rules, identities, and authentication settings.
• Telemetry query and evaluation: The service queries supported telemetry sources by using the model's identity and authentication settings. Source availability, telemetry freshness, permissions, and connectivity determine whether the model can evaluate each signal.
• Submitted health reports: External systems submit health observations directly to the service, so the service doesn't need to query a telemetry source. The service accepts a report and recalculates health in separate stages.
• Health-state aggregation: The service combines signal states into entity health and rolls health up through relationships to show how entity health affects parent entities and the overall model.
• Current health and health history retrieval: The service provides separate views for the latest calculated health state and health over time. Because these views update independently, a recent evaluation might appear in one before the other.
• Health-based alerting: The service evaluates alert rules against health state, then uses Azure Monitor alerts and action groups for notification and automation.

Each path can fail and recover independently.

For more information about how health models work, see Azure Monitor health model concepts.

Physical architecture

When you create a health model, select a supported Azure region. The service associates the model's configuration, evaluations, current health, health history, and model-scoped operations with that region. The service automatically provides zone redundancy.

Resilience to dependency failures

A health model depends on telemetry providers, data stores, identities, network access, health report producers, and Azure Monitor alerting components. The reliability of these dependencies affects the service paths that use them.

A health model can remain reachable even when a dependency prevents fresh evaluation or alert delivery. You're responsible for maintaining the telemetry, identity, network, health report producer, and alert-delivery dependencies that you configure.

• Telemetry providers and data stores: Supported providers include Log Analytics workspaces, Azure Monitor workspaces, Azure Monitor metrics, Prometheus, Application Insights, and Resource Health. If a provider or its telemetry is unavailable, delayed, or incomplete, an affected signal might not receive a fresh evaluation. Entity and model health can then become stale. Each provider has its own regional and reliability behavior.

• Identities, permissions, and network access: The service must authenticate to each configured source and reach it. Evaluation or discovery stops when an identity, role assignment, or network rule blocks that access. Restore access, then confirm that evaluations are fresh again.

• Health report producers: External systems that submit health reports must remain available, and they must submit a new report before the current one expires. If a producer stops submitting reports, its reports expire and no longer provide a current health observation.

• Azure Monitor alerts and action groups: A calculated health-state change doesn't guarantee that the service will deliver a notification or trigger an automation action. Maintain an operational path that doesn't rely solely on this alert chain.

For identity and workspace permission requirements, see Create an Azure Monitor health model. For supported telemetry and alerting, see the Azure Monitor health models overview.

Resilience to transient faults

Transient faults are short, intermittent failures in components. They occur frequently in a distributed environment like the cloud, and they're a normal part of operations. Transient faults correct themselves after a short period of time. It's important that your applications can handle transient faults, usually by retrying affected requests.

All cloud-hosted applications should follow the Azure transient fault handling guidance when they communicate with any cloud-hosted APIs, databases, and other components. For more information, see Recommendations for handling transient faults.

A transient fault can affect one service path while other paths continue to work.

• Transient faults during management and configuration operations: A management request can fail before processing, after the service accepts the change, or lose its response. Treat a timeout or lost response as an uncertain outcome. Check the resource and operation state before you resubmit the request. Keep operation identifiers, use stable resource identities, and use idempotent or conditional operations where the API supports them.

• Transient faults while querying health signals: A transient fault can prevent the health model from receiving or evaluating valid signal data, such as when it can't query a telemetry source. The affected signal can show an Unknown state. Evaluations normally follow the interval configured for the signal but might be delayed during a sustained failure. Health history records an Unknown state when an evaluation produces one, and the health timeline shows it. Health model alerts target Degraded or Unhealthy entity states, so an Unknown state doesn't trigger an alert.

  When the health model can retrieve valid data again, the signal returns to its current calculated health state. The service doesn't retroactively calculate or show the health states that the signal might have had while it couldn't retrieve data. The first successful evaluation records the newly calculated signal state. Normal alert behavior applies if the entity enters a configured alerting state. The entity's health state depends on the states of all its signals and the aggregation configuration for the entity.

  For example, if someone removes the signal's authorization to read data from an entity's target resource, the signal returns an Unknown state and usually shows an error message that explains why it can't retrieve the data. After you restore the authorization, the signal can read the target resource again and returns its current calculated health state. The service doesn't calculate or show the signal states for the period when authorization was unavailable.

• Transient faults during submitted health report ingestion: A successful request returns 204 No Content, but health recalculation can take a few seconds. Don't interpret the absence of an immediate state change as a submission failure. When you submit a health report, treat a timeout or lost response as an uncertain outcome. If you retry a health report for the same entity and signal, the retried report replaces the previous report instead of creating a duplicate.

• Transient faults during current health and health history retrieval: A fault can temporarily prevent you from retrieving current health or health history while other service paths continue to work. Retry eligible failed retrieval requests by using the guidance after this list.

• Transient faults during health-based alerting: A transient fault during Azure Monitor alert-rule processing, action group processing, or notification delivery can delay an alert even when health evaluation succeeds.

If a management, health report submission, or health retrieval request fails with a transient status code, retry the request. For HTTP 5xx responses, retry once or twice at most. If the response includes a Retry-After header, wait for the specified duration before you retry. If the failure persists, open an Azure support request. Don't retry validation, authentication, authorization, or configuration failures until you fix the cause.

Resilience to availability zone failures

Availability zones are physically separate groups of datacenters within an Azure region. When one zone fails, services can fail over to one of the remaining zones.

Azure Monitor health models is zone-redundant. Microsoft distributes the service infrastructure across multiple availability zones in the region. If one zone fails, the service uses infrastructure in the remaining healthy zones. You don't select zones or configure zone redundancy.

Zone redundancy for Azure Monitor health models doesn't make its telemetry, identity, network, and alerting dependencies zone-resilient. Evaluate each dependency separately.

Requirements

Region support: Zone redundancy is supported in regions where both of these conditions apply:

• Azure Monitor health models is available.

• The region supports availability zones. For a list of regions with availability zones, see Azure regions list.

Cost

Zone redundancy doesn't affect the cost of Azure Monitor health models.

Configure availability zone support

You don't configure availability zone support. Create and use the model through its normal regional resource and endpoints. Microsoft manages the service's placement within the region and its response to a zone failure.

Behavior when all zones are healthy

This section describes what to expect when all availability zones used by Azure Monitor health models are operational.

• Cross-zone operation: Use the normal regional endpoint and service paths described in Reliability architecture overview. Microsoft manages the service's placement and operation across availability zones.

• Cross-zone data replication: Microsoft manages the storage and distribution of health model configuration and data across availability zones. You don’t configure cross-zone replication.

Behavior during a zone failure

This section describes what to expect when an availability zone used by Azure Monitor health models is unavailable.

• Detection and response: Microsoft detects and responds to the zone failure. You don't select a surviving zone or initiate failover.

• Notification: Microsoft doesn't automatically notify you when a zone is down. However, you can use Azure Service Health to understand the overall health of the service, including any zone failures, and you can set up Service Health alerts to notify you of problems.

• Active requests: The service continues to work through the normal regional endpoint during a zone failure. In-flight requests or operations might be interrupted. If a management operation fails, follow the guidance in Resilience to transient faults.

• Expected data loss: A zone failure doesn't affect previously committed model configuration or health data. However, the service might miss some signal evaluations while it restores capacity in the remaining zones. Missed signal evaluations appear as periods of Unknown health state in the health history.

• Expected downtime: Azure Monitor health models might experience a brief interruption while the platform redistributes service operation to healthy zones.

  A zone failure might affect your dependencies and block fresh evaluations or notifications. Ensure that your dependencies are resilient to zone failures.

• Traffic rerouting: Microsoft manages the use of service infrastructure in the remaining healthy zones. You continue to use the normal regional endpoint.

Zone recovery

A single-zone failure shouldn't require any recovery action from you. Microsoft manages service recovery, and you keep using the normal regional endpoint.

Test for zone failures

You can't start a zone failover for the service, and you don't need a specific zone-failure test for your health model.

However, you're responsible for testing the resilience of your own telemetry sources, identities, network paths, alert rules, action groups, and notification destinations.

Resilience to region-wide failures

Each health model is associated with the region that you select when you create it. A region failure might make one or more service paths unavailable or degraded, including model management, signal processing and evaluation, current health and health history retrieval, and health-based alerting. Service paths might recover at different times. During a full outage of the selected region, expect the whole model to be unavailable. Azure Monitor health models doesn't provide built-in cross-region resilience, automatic regional failover, or a secondary region that you can configure.

We don't expect to lose existing model data during a region failure. This protection doesn't apply to requests or health reports that the service didn't accept. Microsoft manages regional service recovery, and you can use the model again after its regional service paths recover.

Custom multiregion solutions for resiliency

If you need health models in multiple regions, you must deploy and operate an independent model in each region. Azure Monitor health models doesn't synchronize model configuration, current health, health history, or identity settings between models. You must also configure each model's dependencies separately. If a region fails, a model in another region doesn't take over automatically.

Keep the model definitions reproducible, and use your deployment process to apply configuration changes consistently to every model. Configure and maintain each model's identities, telemetry sources, network access, alert rules, action groups, and other dependencies. You must also decide which model your operators and automation use if one region is unavailable.

Backup and restore

Azure Monitor health models doesn't provide a native backup capability. Plan recovery separately for model configuration, calculated health, and source telemetry. You can't restore them as one unit.

• Health model configuration: Health model configuration includes entities, relationships, signals, discovery rules, and authentication settings. Keep the intended definition in source control, and deploy it by using infrastructure as code or another repeatable process. Periodically verify that you can use the saved definition to create a valid health model and reestablish its identities, permissions, telemetry sources, workspaces, alert rules, and action groups.

  Deleting an Azure Monitor health model removes its entities, relationships, signals, and configuration. The Azure resources represented by the model remain in place. Recreating a model from a saved definition creates a new model deployment. It doesn't restore the deleted resource.

• Current health and health history: The service calculates current health and health history. Recreating the model configuration doesn't restore the previous model's current health or history. The recreated model generates new results as its inputs become available.

• Source telemetry: Source telemetry remains in its originating resources and Azure Monitor data stores. Those services control its retention, backup, export, and recovery. Protect each source according to its lifecycle guidance, such as Log Analytics workspace data retention. Recovering source telemetry doesn't restore current health or health history for a deleted model.

Resilience to service maintenance

Microsoft regularly applies service updates and performs other maintenance. The Azure platform handles these activities automatically, ensuring that maintenance is seamless and transparent to you. No downtime is expected during maintenance events unless you've been advised through Azure Service Health planned maintenance.

Related content

• Azure Monitor health models overview
• Create an Azure Monitor health model
• Analyze Azure Monitor health models