AKS Cluster Has No Log Analytics Monitoring

When an AKS cluster goes sideways at 2am, the difference between a five-minute fix and a multi-hour outage usually comes down to one thing: do you have the data to see what happened? A cluster running without Log Analytics monitoring is a cluster running blind. You get no centralized container logs, no node-level metrics, and no historical record to investigate incidents after the fact.

The aks_nologging check looks at each AKS cluster in your Azure subscriptions and verifies whether the monitoring add-on (historically called the OMS agent, now part of Azure Monitor Container Insights) is enabled and wired to a Log Analytics workspace. If it is not, the check fails.

---

What this check detects

The check inspects the addonProfiles on your AKS cluster definition and looks specifically for the omsagent add-on. When monitoring is enabled, this profile is present, marked as enabled, and references a Log Analytics workspace resource ID. When it is missing or disabled, the cluster has no managed pipeline shipping logs and metrics into Azure Monitor.

Concretely, a passing cluster looks like this when you inspect it:

{
  "addonProfiles": {
    "omsagent": {
      "enabled": true,
      "config": {
        "logAnalyticsWorkspaceResourceID": "/subscriptions/.../workspaces/my-workspace"
      }
    }
  }
}

A failing cluster either has no omsagent key at all, or has it set to "enabled": false.

---

Why it matters

Monitoring is one of those things that feels optional right up until the moment you desperately need it. Here is what you lose when an AKS cluster has no Log Analytics integration.

You cannot investigate incidents

Container logs in Kubernetes are ephemeral. When a pod is rescheduled, evicted, or crashes and gets cleaned up, its logs go with it unless something captured them first. Without Log Analytics, kubectl logs is your only window, and it only shows you what is alive right now. If an attacker dropped a malicious container that ran for ten minutes and exited, you have no record it ever existed.

You miss security signals

Container Insights collects kube-system events, node syslog, and control plane logs (when diagnostic settings are also configured). These are the breadcrumbs you follow during an investigation: a privileged container spinning up, repeated failed image pulls from an unexpected registry, a node suddenly maxing out CPU because someone is mining crypto on your infrastructure. No logs, no breadcrumbs.

You fly blind on reliability

Beyond security, monitoring is how you catch noisy neighbors, memory leaks, and capacity problems before they cause an outage. Container Insights surfaces per-node and per-pod resource consumption, restart counts, and OOMKilled events. Teams running without it tend to find out about problems from angry users instead of dashboards.

---

How to fix it

You can enable monitoring on an existing cluster in a single command. First, decide whether to use an existing Log Analytics workspace or let Azure create a default one. Reusing a workspace is usually the better call so all your cluster data lands in one place.

Option 1: Azure CLI on an existing cluster

Find or create a workspace, then enable the add-on:

# Create a Log Analytics workspace (skip if you already have one)
az monitor log-analytics workspace create \
  --resource-group my-rg \
  --workspace-name my-aks-logs \
  --location eastus

# Grab the workspace resource ID
WORKSPACE_ID=$(az monitor log-analytics workspace show \
  --resource-group my-rg \
  --workspace-name my-aks-logs \
  --query id -o tsv)

# Enable the monitoring add-on on the cluster
az aks enable-addons \
  --addon monitoring \
  --name my-aks-cluster \
  --resource-group my-rg \
  --workspace-resource-id "$WORKSPACE_ID"

Option 2: Enable at cluster creation

az aks create \
  --resource-group my-rg \
  --name my-aks-cluster \
  --node-count 3 \
  --enable-addons monitoring \
  --workspace-resource-id "$WORKSPACE_ID" \
  --generate-ssh-keys

Option 3: Terraform

If you manage AKS with Terraform, add the oms_agent block to the cluster resource. This keeps the configuration in code so it cannot drift back to an unmonitored state.

resource "azurerm_log_analytics_workspace" "aks" {
  name                = "my-aks-logs"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  sku                 = "PerGB2018"
  retention_in_days   = 90
}

resource "azurerm_kubernetes_cluster" "main" {
  name                = "my-aks-cluster"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "myaks"

  default_node_pool {
    name       = "default"
    node_count = 3
    vm_size    = "Standard_DS2_v2"
  }

  identity {
    type = "SystemAssigned"
  }

  oms_agent {
    log_analytics_workspace_id = azurerm_log_analytics_workspace.aks.id
  }
}

Verify the fix

Confirm the add-on is enabled and the agent pods are running:

# Check the add-on profile
az aks show \
  --name my-aks-cluster \
  --resource-group my-rg \
  --query "addonProfiles.omsagent.enabled"

# Confirm the agent DaemonSet is healthy
kubectl get pods -n kube-system -l rsName=ama-logs

---

How to prevent it from happening again

Enabling monitoring once is easy. Keeping every cluster monitored as your fleet grows is the real challenge. Bake the requirement into your delivery pipeline so an unmonitored cluster never reaches production.

Use Azure Policy to enforce it

Azure ships a built-in policy that audits or denies AKS clusters without Container Insights. Assigning it with the DeployIfNotExists effect will automatically remediate clusters as they are created.

# Assign the built-in "Azure Kubernetes Service clusters should have
# Azure Monitor enabled" policy at a subscription scope
az policy assignment create \
  --name "require-aks-monitoring" \
  --display-name "Require Azure Monitor on AKS" \
  --policy "" \
  --scope "/subscriptions/" \
  --location eastus \
  --mi-system-assigned \
  --params '{"logAnalyticsWorkspaceResourceId": {"value": "'"$WORKSPACE_ID"'"}}'

Gate it in CI/CD

If your clusters are defined in Terraform, run a policy-as-code check during pull requests. A simple Open Policy Agent / Conftest rule against the Terraform plan can fail the build when the oms_agent block is missing:

package aks

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "azurerm_kubernetes_cluster"
  not resource.change.after.oms_agent
  msg := sprintf("AKS cluster '%s' must define an oms_agent block", [resource.address])
}

---

Best practices

• Centralize your workspace. Point all AKS clusters in an environment at a shared Log Analytics workspace. Cross-cluster queries and consistent retention are much easier when the data lives in one place.
• Set retention deliberately. Thirty days is a common default, but security investigations often need 90 days or more. Match retention to your compliance obligations, and archive older data to cheaper storage if cost is a concern.
• Add diagnostic settings for the control plane. The monitoring add-on covers node and container data, but API server, audit, and scheduler logs come from a separate diagnostic setting on the cluster resource. Enable both for full coverage.
• Filter noisy data. Use data collection rules to exclude high-volume, low-value logs (verbose system namespaces, for example) so your ingestion bill stays sane without sacrificing the signals that matter.
• Wire up alerts. Collecting data is half the battle. Configure metric alerts for OOMKilled pods, node not-ready states, and persistent restart loops so monitoring becomes proactive rather than purely forensic.

The clusters that survive incidents are not the ones that never break. They are the ones where someone can look back at exactly what happened. Monitoring is what makes that possible.

Enabling Log Analytics on AKS is a small, cheap change with an outsized payoff. It turns a black box into something you can actually reason about, which is the whole point of running a managed Kubernetes service in the first place.