Diagnostic logs in Azure Stream Analytics should be enabled

What does the recommendation "Diagnostic logs in Azure Stream Analytics should be enabled" check?

Flags any Stream Analytics job that has no diagnostic setting routing its resource logs to a Log Analytics workspace, storage account or event hub. Stream Analytics emits two resource log categories: Authoring (job creation, input and output changes, query edits, start and stop events) and Execution (connectivity and data processing errors raised while the job runs). The control only confirms that a destination exists for these logs; it does not check that both categories are actually selected, that the destination is retained for any minimum period, or that the platform metrics under AllMetrics are also being collected. It is scoped to the per-job diagnostic setting in Azure Monitor, not to the activity log on the subscription, which records management-plane writes but none of the job-level authoring or execution detail this control cares about.

Why does "Diagnostic logs in Azure Stream Analytics should be enabled" matter?

A Stream Analytics job sits in the data path for telemetry, fraud signals and operational events, yet its resource logs are off by default and cannot be recovered retrospectively: nothing is buffered before a diagnostic setting exists. With no setting in place, an Authoring entry that shows who altered a query or repointed an output to a different sink, or an Execution entry that explains why records were silently dropped, simply never exists. When a downstream dashboard goes wrong or an investigator asks who changed the pipeline, there is no activity trail to reconstruct events from, so quiet tampering or a data-loss incident can go unrecognised for weeks and cannot be proven either way. The business cost is twofold: incidents take far longer to scope, and a regulator or auditor asking you to demonstrate who touched a personal-data stream gets met with silence.

How do I fix "Diagnostic logs in Azure Stream Analytics should be enabled"?

1. Create a diagnostic setting on the job that captures both log categories: az monitor diagnostic-settings create --name sa-logs --resource <job-resource-id> --workspace <log-analytics-workspace-id> --logs '[{"category":"Authoring","enabled":true},{"category":"Execution","enabled":true}]'.
2. Send the logs to a workspace or storage account that you retain centrally, so the trail outlives the job and a deleted job does not take its evidence with it.
3. Track the baseline at scale by assigning the built-in audit policy. Its effect is AuditIfNotExists, so it flags any job that has no diagnostic setting as non-compliant: it reports the gap but does not deploy or remediate a setting for you, so you still apply the fix above on each flagged job. Look the definition up by display name rather than pasting a GUID: pid=$(az policy definition list --query "[?displayName=='Resource logs in Azure Stream Analytics should be enabled'].name" -o tsv); az policy assignment create --name sa-diag-logs --policy "$pid" --scope <subscription-or-rg-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"