I'm trying to understand how people approach monitoring in production Azure environments. Do you mainly use Azure Monitor, Log Analytics, Application Insights, or a separate observability platform?
How do you track failed requests, slow performance, high CPU or memory usage, dependency problems, and service outages? Do you centralize logs and alerts in one place, or use different tools for different types of resources?
I'd also like to know how you decide which conditions deserve an alert and which information is better left for dashboards or periodic review. Any practical examples of alerting setups would be helpful.
4 Answers
Start with a recommended baseline alert set, but don’t deploy every possible rule without tuning it. Thresholds depend heavily on the workload, expected traffic, scaling limits, and business impact. Useful signals include request volume, resource utilization, error rate, latency, dependency failures, and budget or quota limits. An alert should generally mean either that something is already seriously broken or that a developing trend needs intervention. If nobody knows what action to take when an alert fires, it probably belongs on a dashboard instead. Also be careful with recovery notifications and low-value email alerts, since overly broad rules quickly create alert fatigue.
The built-in Azure tools are often enough, especially for teams already operating in Azure. However, some organizations prefer a third-party platform such as New Relic, Dynatrace, or another observability system for cross-cloud visibility and richer analysis. If portability matters, instrument applications with OpenTelemetry and keep telemetry collection separate from the application code where possible. That makes it easier to change backends later and reduces dependence on a provider-specific SDK. For security monitoring, a dedicated SIEM may be appropriate, while Azure Monitor and Log Analytics can remain the operational monitoring foundation.
A practical setup is to have applications emit structured logs and telemetry into Application Insights, backed by a Log Analytics workspace. Use KQL queries to derive useful metrics, put longer-term trends on dashboards, and create alerts only for conditions that require someone to act. Failed requests and availability checks can come from Application Insights, while resource thresholds come from Azure Monitor. It’s also worth defining the monitoring and alert rules in Terraform or Bicep so every environment is configured consistently. You can create the rules in non-production for testing, but only enable paging in production where appropriate.
That approach also helps keep development environments quiet. I’d normally create the alert definitions everywhere, but use a setting that disables notifications outside production.
Azure Monitor is usually the umbrella, with the other services filling specific roles. Log Analytics provides centralized storage and KQL-based querying, while Application Insights adds application telemetry such as failed requests, response times, dependency tracking, and distributed traces. Azure Monitor metrics and alerts are useful for platform resources like VMs, App Services, containers, databases, CPU, and memory. Service Health alerts cover Azure-side incidents and maintenance. For distributed systems, sending diagnostic data to a shared workspace makes it much easier to reconstruct a failure that moved across several components.
Baseline rules are a good starting point, but I’d treat their thresholds as defaults rather than universal answers. Every customer and workload needs its own tuning.