Azure Monitor helps teams see what is happening inside Kubernetes clusters running on Azure: whether machines are busy, containers are using too much memory, or workloads are producing useful error logs. The historical container-health integration collected these signals for investigation in Azure. Today's setup separates metrics, logs and dashboards, so choose the signals you need and their destinations rather than assuming one installation enables every kind of monitoring.
Deployment and operating notes
The historical package installed the earlier Azure Monitor container-health integration. Microsoft’s current AKS onboarding documentation separates Prometheus metrics, Managed Grafana, container logging and control-plane logs. These features use different destinations and configuration, so enabling one does not establish that all historical dashboards and alerts continue to work.
Inventory existing workspaces, collection rules, diagnostic settings, retention and alert queries before replacing the agent path. Use current AKS-supported onboarding rather than the archived incubator chart, and confirm which features are actually required for each cluster. Check identity permissions and network access to ingestion endpoints, especially for private clusters. During migration, compare a known pod log line, a workload metric and a control-plane event in their respective destinations; also check ingestion volume to detect double collection. Keep old alerting active until equivalent signals are verified. Historical CPU and memory examples describe useful signals, but they do not establish present-day pricing, default retention or full application tracing.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Original publication: 2018-09-06T16:04:44+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
Use Azure Monitor container health to monitor the performance of workloads that are deployed to Kubernetes environments and hosted on Azure Kubernetes Service (AKS). Monitoring your Kubernetes cluster and containers is critical, especially when you’re running a production cluster, at scale, with multiple applications.
Container health gives you performance monitoring ability by collecting memory and processor metrics from controllers, nodes, and containers that are available in Kubernetes through the Metrics API. After you enable container health, these metrics are automatically collected for you through a containerized version of the Log Analytics agent for Linux and stored in your Log Analytics workspace. The included pre-defined views display the residing container workloads and what affects the performance health of the Kubernetes cluster so that you can:
- Identify containers that are running on the node and their average processor and memory utilization. This knowledge can help you identify resource bottlenecks.
- Identify where the container resides in a controller or a pod. This knowledge can help you view the controller’s or pod’s overall performance.
- Review the resource utilization of workloads running on the host that is unrelated to the standard processes that support the pod.
- Understand the behavior of the cluster under average and heaviest loads. This knowledge can help you identify capacity needs and determine the maximum load that the cluster can sustain.
The post AzureMonitor–Containers appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →