Add quickstart: Azure Monitor health model for a three-tier web app

[amy-rich]

PR Checklist

Check these items before submitting a PR...

Contribution Guide

Best Practice Guide

• - Please check this box once you've submitted the PR if you've read through the Contribution Guide and best practices checklist.

Changelog

[alex-frankel]

/validate

[github-actions]

🤖 Quickstart Sample Summary

Sample Summary

• This sample deploys an Azure Monitor health model for a three-tier web application topology, comprising frontend, backend, and data tiers.
• The health model includes logical entities representing app components, reusable signal definitions for monitoring key metrics (such as HTTP response time, API Management failed requests, Cosmos DB availability), and entity relationships.
• Alerts are configured at the root entity level for health statuses like "Sev1 unhealthy" and "Sev3 degraded."
• To deploy, specify the health model name and optionally the Azure location. The deployment provisions the health model, its authentication settings, signal definitions, entities, relationships, and alert rules in one template.

Resources Deployed

All resources are defined in main.bicep and use the resource provider Microsoft.CloudHealth with API version 2026-05-01-preview:

• Microsoft.CloudHealth/healthmodels - The root health model resource.
• Microsoft.CloudHealth/healthmodels/authenticationsettings - Authentication settings for the health model, using system-assigned managed identity.
• Microsoft.CloudHealth/healthmodels/signaldefinitions - Multiple signal definitions for reusable metrics and log signals. Examples include:
  • HTTP Response Time (http-response-time)
  • HTTP 5xx errors (http-5xx)
  • API Management failed requests (apim-failed-requests)
  • Cosmos DB service availability (cosmosdb-availability)
• Microsoft.CloudHealth/healthmodels/entities - Entities representing the 3-tier app components like frontend, web, API gateway, backend API, worker, data, database, cache, etc.
• Microsoft.CloudHealth/healthmodels/relationships - Relationships defining parent-child links between entities, modeling the application topology.
• Microsoft.CloudHealth/healthmodels/alertrules - Alert rules targeting the root entity to notify on degraded or unhealthy states.

No nested or linked templates are used; all resources are declared in the main Bicep file.

Security Findings

No security issues detected by MSDO scanners (Template Analyzer, Checkov, Trivy, Terrascan).

No additional security-sensitive patterns (e.g., hardcoded secrets or overly permissive access) were identified in the templates.

Key Parameters

• healthModelName (string): The name of the health model and root entity.
• location (string, default: resource group location): Location for all deployed resources.

Notes for Reviewers

• The sample provides a comprehensive health model for a web app with clear entity topology and reusable signal and alert definitions.
• The README includes deployment badges and links to Azure Monitor health models documentation.
• No secrets or sensitive data are hardcoded.
• The deployment shows a modern usage of the new Azure Monitor Cloud Health resource types and their relationships.

Files Touched

• main.bicep - Main deployment template containing all resources.
• README.md - Sample documentation with deployment and overview.
• azuredeploy.parameters.json - Parameters file defining default values.
• metadata.json - Sample metadata describing the quickstart.

---

Generated by the quickstart summarizer agent (v2 — agentic + MSDO security) · triggered by /validate

[alex-frankel]

/validate failed — the deployment recorded in testResult (from May) doesn't match the current template. The ADX validator computes a hash of the main.bicep in this PR and compares it against what was recorded at deployment time; since the template was updated on June 16 after that deployment, the hashes diverge.

To fix:

1. Redeploy the current main.bicep from this PR branch to Azure
2. Capture the new correlationId and deploymentName
3. Update metadata.json with those values and push

Wait ~10 minutes after deployment before re-triggering /validate to let ADX ingestion catch up. Let me know once pushed and I'll re-run.