6. Integrations

Azure Monitor is the least island-like service in the catalogue: its entire job is to be wired into everything else. That makes this page less "here are five friends" and more "here are the two glue mechanisms and the shapes they take".

The two glue mechanisms, first

Nearly every "how do these talk to each other" question in Azure resolves to one of these, and both apply heavily here:

• Managed identity + a role assignment. The keyless way one Azure resource authenticates to another. For Azure Monitor: a workload publishing custom metrics gets Monitoring Metrics Publisher on the target resource; a workload pushing to the Logs Ingestion API gets Monitoring Metrics Publisher on the DCR; a Grafana instance reading the workspace gets Monitoring Reader; a Policy assignment's identity gets Log Analytics Contributor on the workspace so it can deploy diagnostic settings. Never a shared key — and set local_authentication_disabled = true on the workspace so keys cannot be used even if one leaks.
• Private endpoint + Private DNS zone. Azure Monitor's version has its own name: an Azure Monitor Private Link Scope (AMPLS). You create the scope, add the workspaces and Application Insights components to it, and attach a private endpoint to the scope rather than to each resource. The private DNS zones involved cover the monitor, oms-opinsights, ods-opinsights, agentsvc, and blob endpoints ⚠️ verify the current zone list. The trap is access modes: setting the scope to Private Only for ingestion or query affects every resource in the scope, including ones added later, and can cut off agents you forgot about. Start in Open mode, verify traffic, then close it.

[Image Prompt: 2D minimalistic hub-and-spoke diagram with a Log Analytics workspace at the centre connected by labelled edges to Azure resources sending diagnostic settings, virtual machines running the Azure Monitor Agent, Application Insights, Event Hubs for export, Microsoft Sentinel, Azure Managed Grafana, Logic Apps and Azure Functions triggered by action groups, and Azure Policy enforcing collection, flat design, clean vector art style, white background]

The pairings that matter

Pairs with	Why	The glue
Every Azure resource	It is the source of all resource logs and platform metrics	A diagnostic setting on the resource, ideally deployed by Azure Policy DeployIfNotExists rather than by hand
Azure Policy	Makes monitoring universal instead of best-effort	DeployIfNotExists assignment at management-group scope, with a managed identity holding Contributor on targets and Log Analytics Contributor on the workspace
Virtual Machines / VM Scale Sets / Azure Arc	Guest-OS metrics, Syslog, Windows event logs, text logs	Azure Monitor Agent extension + a Data Collection Rule + a DCR association. Arc-enabled servers use exactly the same path, which is the main reason Arc exists for many shops
Azure Kubernetes Service	Container logs, control-plane logs, and Prometheus metrics	Container Insights (writes ContainerLogV2 etc. to the workspace via a DCR) plus managed Prometheus writing to an Azure Monitor Workspace. Note these are two destinations, two bills, and two query languages
Application Insights	Application-level traces, requests, dependencies, exceptions	The connection string in app settings, ideally as a Key Vault reference resolved by managed identity; instrument with the Azure Monitor OpenTelemetry Distro for new code
Event Hubs	The supported export door to anything outside Azure	A diagnostic setting destination. This is how Datadog, Splunk, Elastic, and your own consumers get Azure telemetry. Budget for it — the Event Hub is a separate, always-on cost
Storage accounts	Cheap, long-term, compliance-grade archive of raw logs	A diagnostic setting destination. Cheaper than workspace retention but not queryable with KQL; pair with immutability policies where compliance demands it
Microsoft Sentinel	SIEM analytics over the same logs	Enabled on a Log Analytics workspace. Same data, additional meter. Decide deliberately whether security and operations share one workspace — sharing saves ingestion cost, separating simplifies RBAC and billing
Azure Managed Grafana	Better dashboards than the portal, and the tool most SRE teams already know	Managed identity on the Grafana instance with Monitoring Reader on the subscription; Grafana queries both the metrics API and the workspace
Logic Apps / Azure Functions	Doing something automatic when an alert fires — enrich, deduplicate, open a ticket, restart a thing	An action group action targeting the Logic App or Function. Turn on the common alert schema so your handler gets one payload shape rather than five
Azure Automation	Runbook remediation triggered by an alert	Action group → webhook → runbook, or the Automation account's own hybrid worker for in-guest actions
Key Vault	Holding the Application Insights connection string and any webhook secrets	Key Vault reference in app settings, resolved via the app's managed identity
Microsoft Entra ID	Sign-in and audit logs, which are tenant-level, not subscription-level	A diagnostic setting on the tenant's Entra ID, not on a resource — a different blade and a different permission (Security Administrator or Global Reader territory), which is why these logs are so often missing
Azure Front Door / Application Gateway / Firewall	The highest-volume log sources in most estates	Diagnostic settings — and the ones to consider putting on the Basic table plan first
Cost Management	Understanding the bill Azure Monitor generates	The workspace's own Usage table answers "which table costs the most"; Cost Management answers "which subscription". Use both

Wiring notes worth having in your head

Application Insights connection string, not instrumentation key. The instrumentation key is legacy and being retired; new configuration uses APPLICATIONINSIGHTS_CONNECTION_STRING, which carries the regional ingestion endpoint as well as the identifier. ⚠️ Verify the current retirement timeline. Store it as a Key Vault reference rather than a literal app setting.

Entra ID logs are the ones everyone forgets. Sign-in logs, audit logs, and provisioning logs live at tenant scope. If you only ever created diagnostic settings on resources, you have none of them — and they are the first thing anyone asks for during a security investigation. The retention for them in the Entra portal itself is short ⚠️ verify the current value, so exporting is the whole point.

Container Insights defaults are expensive. The out-of-the-box configuration collects container stdout and stderr from every namespace. On a busy cluster this is routinely the single largest line item in an Azure Monitor bill. Tune it in the DCR: exclude kube-system and other noisy namespaces, turn off stdout where you have real structured logging, and consider ContainerLogV2 on the Basic plan.

Autoscale is an Azure Monitor integration, not a compute feature. Microsoft.Insights/autoscaleSettings reads the same metrics store your alerts read. That means a metrics-side problem — a metric that stops being emitted, an aggregation chosen badly — shows up as both a missing alert and a scale set that will not scale. When both break together, look at metrics, not at compute.

Cross-workspace queries are first-class. A federated estate with a workspace per region or per business unit is not a dead end:

union
  workspace("log-shop-prod-uksouth").AzureDiagnostics,
  workspace("log-shop-prod-westeurope").AzureDiagnostics
| where TimeGenerated > ago(1h)
| where ResourceType == "APPLICATIONGATEWAYS" and httpStatus_d >= 500
| summarize errors = count() by _ResourceId, bin(TimeGenerated, 5m)

The reader needs permission on every workspace named, and the query is billed against each. This is the mechanism that makes "one workspace per region for data residency" a workable design rather than a fragmentation problem.

Resource Graph is the other KQL. az graph query runs KQL over resource configuration rather than telemetry — which is how you answer "which resources have no diagnostic setting" without a policy:

az graph query -q "
resources
| where type =~ 'microsoft.keyvault/vaults'
| project id, name, resourceGroup
" -o table

Same language, different store, no ingestion cost. Worth knowing because people reach for a workspace query when a Resource Graph query would have been free and instant.

---

Next: Production →

← Back to the Azure Monitor overview · ← Previous: Deployment