Diagnostic logs in Event Hubs should be enabled

What does the recommendation "Diagnostic logs in Event Hubs should be enabled" check?

Flags any Event Hubs namespace that has no diagnostic setting routing its resource logs to a Log Analytics workspace, storage account or another Event Hub. It looks for the presence of a diagnostic setting that streams categories such as OperationalLogs, RuntimeAuditLogs, ArchiveLogs and KafkaCoordinatorLogs. It is a presence check only: it does not verify that the retention period is long enough, that the destination workspace or storage account is itself secured, or that platform metrics are collected. It also does not enable data-plane RuntimeAuditLogs, which exist only on the premium and dedicated tiers, so a basic or standard namespace can satisfy the control with control-plane logging alone. The underlying built-in policy, 'Resource logs in Event Hub should be enabled', only audits compliance and never changes the resource itself.

Why does "Diagnostic logs in Event Hubs should be enabled" matter?

Without a diagnostic setting, the control-plane and runtime activity on a namespace is discarded after a short rolling window, so there is no durable trail of who created authorisation rules, which clients connected, or when capture to storage failed. If a namespace is used to exfiltrate data or a shared access signature key is abused, you cannot reconstruct the timeline after the fact, because the evidence was never persisted anywhere you can query. The business consequence is a failed incident investigation when it matters most and, for regulated workloads under frameworks that mandate audit logging, an inability to evidence monitoring during an assessment, which can stall a certification. Streaming logs to a Log Analytics workspace gives you queryable, retained records that survive the namespace itself, so you can investigate even after the resource is deleted.

How do I fix "Diagnostic logs in Event Hubs should be enabled"?

1. Create a diagnostic setting on the namespace that ships the log categories to Log Analytics: az monitor diagnostic-settings create --name eh-diag --resource <namespace-resource-id> --workspace <workspace-resource-id> --logs '[{"category":"OperationalLogs","enabled":true},{"category":"ArchiveLogs","enabled":true},{"category":"RuntimeAuditLogs","enabled":true}]'.
2. Enforce it at scale by assigning the built-in policy by display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='Resource logs in Event Hub should be enabled'].name" -o tsv); az policy assignment create --name eh-diaglogs --policy "$pid" --scope <subscription-or-mg-scope>. Note this definition only audits, so pair it with a deployIfNotExists 'Configure diagnostic settings' policy if you want automatic remediation.
3. Bake the diagnostic setting into your Bicep namespace module with a Microsoft.Insights/diagnosticSettings resource scoped to the namespace, setting workspaceId and the logs array, so every new namespace ships logging on day one.

# Turn on the security-relevant App Service logs and send them to a workspace.
WS=$(az monitor log-analytics workspace show \
  -g central-logging -n estate-logs --query id -o tsv)

for id in $(az webapp list --query "[].id" -o tsv); do
  has=$(az monitor diagnostic-settings list --resource "$id" \
        --query "length(value)" -o tsv)
  if [ "$has" = "0" ]; then
    az monitor diagnostic-settings create \
      --name to-log-analytics \
      --resource "$id" \
      --workspace "$WS" \
      --logs '[{"category":"AppServiceHTTPLogs","enabled":true},
               {"category":"AppServiceAuditLogs","enabled":true},
               {"category":"AppServiceConsoleLogs","enabled":true}]'
    echo "$(basename "$id"): diagnostic logging enabled to estate-logs"
  fi
done

# Ratchet it shut: built-in policy adds the setting to any new App Service.
az policy assignment create \
  --name deploy-appservice-diag \
  --policy 0c6cd767-1a1d-484b-a897-68e398c03aeb \
  --location uksouth \
  --mi-system-assigned \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"