AKS clusters with the Container insights monitoring add-on switched off
What does ZopNight detect here?
ZopNight flags an AKS cluster when Azure reports its Container insights add-on, listed as `omsagent` under the cluster's addon profiles, as disabled. Without it, node health, pod performance and container logs never reach a Log Analytics workspace, so capacity problems surface as outages instead of alerts. The finding carries no dollar saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1352 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | omsagent add-on disabled |
| Source | ZopNight |
| Permissions used | Microsoft.ContainerService/managedClusters/read |
Where it applies
What AKS gives you for free and what it does not
Azure collects AKS platform metrics and activity log entries automatically and at no charge, per the AKS monitoring overview. Those tell you the cluster exists and roughly how busy the control plane is. They do not tell you which node is out of memory, which pod is restarting, or what a crashing container printed before it died.
That view comes from Container insights, which runs a containerized Azure Monitor agent on
the nodes and writes inventory, performance data and container logs to a Log Analytics
workspace. In the cluster’s resource definition the add-on appears as omsagent under
addonProfiles.
Checking the add-on on your clusters
az aks show --resource-group my-rg --name my-aks \ --query addonProfiles.omsagent.enabledfalse, or no omsagent entry at all, means Container insights is not collecting from the
cluster.
What has to be true for the finding
The finding fires only when Azure’s description of the cluster reports the Container insights add-on as disabled. ZopNight does not look at metrics or wait out a window: the state is read on each scan, and turning the add-on on clears the finding on the next one.
Clusters ZopNight does not flag
When the add-on’s state is missing from what Azure returned, the cluster is treated as unknown and left alone. Monitoring labels or tags you put on the cluster are not consulted. This check also says nothing about control-plane logs, which are configured separately through diagnostic settings and covered by AKS Cluster Diagnostic Logging Not Enabled.
Visibility, paid for in Log Analytics
There is no saving attached to this compliance finding. Enabling Container insights adds Log
Analytics ingestion cost, which you can control: Microsoft documents data collection rule
settings to choose tables, collection intervals and excluded namespaces, and the
ContainerLogV2 schema supports the cheaper Basic logs tier. The risk of skipping it is that
resource bottlenecks are found by users first.
Enabling Container insights
- Choose the Log Analytics workspace that should hold the cluster’s data.
- Enable the add-on on the existing cluster, as shown in Enable monitoring for AKS:
az aks enable-addons --addon monitoring \ --name my-aks --resource-group my-rg \ --workspace-resource-id /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<ws>- Review the data collection settings and exclude noisy namespaces before volume builds up.
- Turn on the recommended alert rules for node and pod health so problems page someone.