Diagnostic logs in Batch accounts should be enabled

What does the recommendation "Diagnostic logs in Batch accounts should be enabled" check?

Flags any Azure Batch account that has no diagnostic setting forwarding its resource logs, so the 'ServiceLog' category (events the Batch service emits over the lifetime of a pool, job or task) is not being captured to a Log Analytics workspace, storage account or Event Hub. It checks only that a diagnostic setting exists and routes those logs to a destination. It does not verify the retention period you keep them for, whether a human or alert ever reads them, or that the destination workspace itself is secured. It also says nothing about node-level operating system logs or the application output of code running inside your compute nodes, none of which Batch emits through this channel. To capture those you would ship logs off the nodes yourself, for example with the Azure Monitor agent or a custom start task, which this control neither checks nor satisfies.

Why does "Diagnostic logs in Batch accounts should be enabled" matter?

Batch runs large, often privileged compute fleets that scale up and tear down in minutes, so the only durable evidence of what happened lives in the service logs. With no diagnostic setting, the pool, job and task events vanish as nodes deallocate, leaving you unable to reconstruct who launched what, why a pool resized at three in the morning, or how a compromised node behaved before it was recycled. After a security incident or a customer dispute that gap means a forensic investigation has nothing to work from and a compliance audit fails on its logging requirement. Enabling diagnostics is cheap and one-time, whereas recreating lost activity trails after the fact is impossible, so the cost of leaving it off lands precisely when you can least afford it.

How do I fix "Diagnostic logs in Batch accounts should be enabled"?

1. On the Batch account, open Monitoring then Diagnostic settings and add a setting that enables the 'ServiceLog' category (or the 'allLogs' category group) plus 'AllMetrics', and send it to a Log Analytics workspace you retain and monitor.
2. To script it, run: az monitor diagnostic-settings create --name batch-diag --resource <batch-account-id> --workspace <log-analytics-workspace-id> --logs '[{"category":"ServiceLog","enabled":true}]' --metrics '[{"category":"AllMetrics","enabled":true}]'
3. To enforce it across the estate, assign the built-in policy by looking up its ID rather than hardcoding a GUID: pid=$(az policy definition list --query "[?displayName=='Resource logs in Batch accounts should be enabled'].name" -o tsv); az policy assignment create --name batch-diag-logs --policy "$pid" --scope <subscription-or-management-group-scope>

# 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"