Observability implementation guide

Repository layout

observability/infra/main.bicep is the single subscription-scope deployment entry point. It composes only package resources and never references a workload template. Each module has one Azure resource responsibility. Public profile files demonstrate the complete input contract, while private overlays contain values that are specific to a tenant or deployment.

Area	Contents
infra/modules	Resource group, workspaces, budget, action group, alerts, policy assignments, diagnostics, Application Insights, DCRs, dashboard, health model, and routing modules
infra/parameters	Public profile examples with fictitious recipients and placeholder scopes only
dashboards	Versioned dashboard-definition source and authoring notes
queries/resource-graph	Resource inventory, tag, lifecycle, and ownership queries
pipelines	Reusable Plan, Provision, Configure, Validate pipeline template

Deployment lifecycle

1. Select a public profile closest to the desired capability.
2. Copy it into the consuming repository's ignored private deployment area.
3. Replace all placeholder values and add any approved alert, policy, diagnostic, or query definitions. Keep emails, scopes, destinations, and budget values private.
4. Compile Bicep and run subscription what-if through the consuming pipeline.
5. Review name, scope, tags, resource changes, expected alert count, data-producing features, and costs.
6. Obtain the deployment owner's approval, then provision through the pipeline.
7. Configure only the approved workload-side settings, such as a diagnostic category or an application instrumentation connection.
8. Validate resource existence, tags, alert delivery, budget notification, query output, and dashboard panels. Record the as-built state in the consumer runbook.

No module invokes an Azure CLI create command. Deployment is declarative Bicep and remains separate from core workload deployment.

Module composition

Module group	Resource purpose	Profile
Foundation	Resource group, Log Analytics workspace, Azure Monitor Workspace, action group, budget, dashboard shell	Foundation
Governance and FinOps	Policy assignments, Cost Management scheduled actions, exports	Solution core when approved
Control plane and health	Activity Log alerts, Activity Log diagnostic setting, metric alerts, alert processing rules	Solution core when approved
Workload diagnostics	Foundry diagnostic setting, Application Insights, availability tests, scheduled query alerts	Solution diagnostics
Hybrid and preview	Data collection rules, health model preview	Hybrid extension or explicit pilot

Dashboard implementation

Use the native Azure Monitor dashboard with Grafana resource, not Azure Managed Grafana. The package can create the dashboard shell. Dashboard-definition deployment uses the current preview ARM child type and is therefore a separate opt-in switch. Before enabling it, export or author the dashboard JSON in source control, review its data sources and queries, and validate that it contains no private URLs, credentials, or personal data.

The initial dashboard set must include:

1. Cost actual and forecast against budget, with a link to Cost Management.
2. Inventory by type, region, Owner, Project, Lifecycle, and ExpiresOn.
3. Untagged and expired temporary resources.
4. Control-plane changes, failed deployments, Service Health, Resource Health, and active alerts.
5. Workload-specific standard metric panels only for metrics the target resource actually supports.

Query library

Resource Graph queries are stored as source because they do not require workspace ingestion. They supply the inventory, ownership, lifecycle, and tag-compliance views that a dashboard or an operator can execute with Reader access. Queries must not join private data sources or contain tenant identifiers.

Workload integration contract

A workload repository supplies a thin configuration layer:

• scopes of its existing resources;
• supported metric-alert definitions, including metric namespace and dimensions;
• optional approved diagnostic categories;
• source-controlled dashboard definition and panels;
• links to workload-specific alert runbooks.

It does not redefine the common resource group, workspaces, action group, budget, tag policy, or generic cost controls. A reusable enhancement is implemented in Platform first and then consumed by the workload repository.