After Lab 4.1 — Recap
After Lab 4.1 — Recap
You ran the Day 4 pipeline and observed the baseline. You enabled monitoring infrastructure — diagnostic settings, OpenTelemetry-based SDK integration, and Microsoft Sentinel — on the existing Day 3 resources.
What You Should Understand
Terraform Plan Output — Reading the Changes
The terraform plan output for Day 4 should show changes like:
Terraform will perform the following actions:
# azurerm_monitor_diagnostic_setting.public_backend will be created
+ resource "azurerm_monitor_diagnostic_setting" "public_backend" {
+ name = "diagnostic-settings-http"
+ log_analytics_workspace_id = (known after apply)
+ target_resource_id = (known after apply)
+ enabled_log {
+ category = "AppServiceHTTPLogs"
+ enabled = true
}
+ enabled_log {
+ category = "AppServiceConsoleLogs"
+ enabled = true
}
+ enabled_log {
+ category = "AppServiceAppLogs"
+ enabled = true
}
+ metric {
+ category = "AllMetrics"
+ enabled = true
}
}Key observations:
- Diagnostic settings are new resources — they route platform logs to the Log Analytics workspace
- Sentinel is enabled interactively in the Azure portal during Lab 4.4 (not via Terraform)
- Daily cap is set in the Azure portal during Lab 4.2 to prevent runaway costs
Why Monitoring Is Added to Existing Resources
Day 4 doesn't create new resources — it enables monitoring on resources created in previous days. The full resource table and architecture is in Day 4 overview. The key idea is simple: you enable monitoring on what's already there, you don't redesign your infrastructure to fit monitoring.
Reflection Questions
Why enable diagnostic settings on the dev environment when production will have them anyway?
Learning and validation: In production, you enable diagnostic settings on all environments. In the lab, the dev environment is your only environment. Enabling them in dev lets you:
- Test the data pipeline: Verify that logs flow from resource → diagnostic settings → Log Analytics → Sentinel
- Validate KQL queries: Write and test queries against real data before applying to production
- Reduce risk: A mistake in dev costs nothing; a mistake in production costs downtime
Once you verify the flow in dev, you apply the same configuration to prod.
Common Issues
| Issue | Symptom | Cause | Fix |
|---|---|---|---|
| Sentinel not visible in portal | Cannot find Sentinel in Azure Portal | Sentinel must be enabled manually in the portal | Go to Log Analytics workspace → Sentinel → Enable |
| No logs flowing to Log Analytics | KQL queries return empty results | Diagnostic settings take 5-30 seconds to start routing | Wait and verify with a KQL query: AzureDiagnostics | take 10 |
| Pipeline fails on Terraform plan | terraform plan fails with error | Resource group permissions incorrect | Verify the managed identity has Contributor role on the resource group |
| Daily cap not set | Log Analytics costs could spike | Daily cap is configured in the portal, not Terraform | Set the daily cap in the Log Analytics portal during Lab 4.2 |
Bridge to Lab 4.2
You have enabled monitoring infrastructure and observed the baseline. The resources are configured, but the data has not started flowing yet. In the next lab, you will route infrastructure logs to Log Analytics and verify that the data pipeline works.