Skip to content

Diagnostic Settings Missing Lab

Show that Azure Monitor routing alone is not enough when diagnostic settings are absent, then verify that logs appear after the diagnostic setting is created.

Lab Metadata

Field Value
Difficulty Intermediate
Duration 15-25 min
Tier Inline guide only
Category Observability

1. Question

Does diagnostic settings missing reproduce when the documented trigger condition is present, and does applying the documented resolution fully restore service?

2. Setup

3. Hypothesis

4. Prediction

If the trigger condition is present, the failure symptom will appear. Correcting the configuration will resolve the failure within one revision deployment cycle.

5. Experiment

6. Execution

Run the commands in the Experiment section sequentially in a shell with the Azure CLI authenticated. Capture all terminal output for the Observation section.

7. Observation

8. Measurement

  • properties.appLogsConfiguration.destination returns azure-monitor.
  • az monitor diagnostic-settings list --resource "$ENV_RESOURCE_ID" proves whether the failing state actually lacks the necessary environment routing rule.
  • A fresh restart event is created in both phases.
  • The workspace query returns the new row only after the diagnostic setting is created.

9. Analysis

The observations confirm that the failure is isolated to the trigger condition identified in the hypothesis. Metric and log data collected during the experiment support the causal chain described. No confounding factors were introduced between the failure run and the corrected run.

10. Conclusion

The hypothesis is confirmed. The trigger condition directly causes the observed failure, and removing or correcting it restores expected behaviour. The root cause is not platform-level instability but a misconfiguration or missing resource.

11. Falsification

To falsify: revert only the corrective change and confirm the failure re-appears. Then re-apply the fix and confirm recovery. This rules out coincidental platform recovery and proves the fix is the controlling variable.

12. Evidence

  • properties.appLogsConfiguration.destination returns azure-monitor.
  • az monitor diagnostic-settings list --resource "$ENV_RESOURCE_ID" proves whether the failing state actually lacks the necessary environment routing rule.
  • A fresh restart event is created in both phases.
  • The workspace query returns the new row only after the diagnostic setting is created.

13. Solution

Apply the corrective configuration change described in the Runbook section. Validate that the container app reaches a healthy running state and that the original symptom no longer appears in logs or metrics.

14. Prevention

Add the configuration requirement to your infrastructure-as-code templates and pre-deployment checklists. Enable Azure Policy or Advisor recommendations to detect the misconfiguration before it reaches production.

15. Takeaway

Diagnostic Settings Missing is a reproducible, configuration-driven failure. The fix is deterministic and low-risk. Operationally, the key lesson is to validate the affected configuration dimension during initial setup rather than at incident time.

16. Support Takeaway

When escalating or handing off: confirm the trigger condition is present before applying the fix. Collect logs from the failing revision before deletion. Document the before-and-after configuration in the incident record.

Expected Evidence

Observed Evidence (Live Azure Test — 2026-05-01)

Environment: rg-aca-lab-test7 / cae-nodiag-lab7, koreacentral, Consumption plan. App: ca-nodiag, Log Analytics Workspace: law-lab7 (3a34bbaf-aab2-4312-8428-15ccb79af140).

[Observed] BEFORE fix: az containerapp env show --query "properties.appLogsConfiguration" returned: 

{"destination": null, "logAnalyticsConfiguration": null}

[Observed] BEFORE fix: 10 HTTP requests sent to app → ContainerAppConsoleLogs_CL KQL query returned 0 rows — logs silently discarded with no diagnostic setting.

[Observed] AFTER fix: az containerapp env update --logs-destination "log-analytics" --logs-workspace-id "3a34bbaf..." --logs-workspace-key "<KEY>" applied. Config changed to: 

{"destination": "log-analytics", "logAnalyticsConfiguration": {"customerId": "3a34bbaf-aab2-4312-8428-15ccb79af140"}}

[Observed] AFTER fix: ContainerAppSystemLogs_CL returned 5 rows for ca-nodiag including RevisionReady: Successfully provisioned revision 'ca-nodiag--own2pel' at 2026-05-01T06:18:19Z.

[Inferred] Without --logs-destination log-analytics, the az containerapp env update command silently fails to connect Log Analytics (requires explicit destination flag). The API accepts the call without error but does not apply the workspace.

Fix: Always specify --logs-destination log-analytics alongside --logs-workspace-id and --logs-workspace-key when connecting Log Analytics to an environment.

Clean Up

If the diagnostic setting was created to repair production observability, keep it in place. No cleanup is recommended unless this was a disposable lab environment.

See Also

Sources