-
Notifications
You must be signed in to change notification settings - Fork 95
Monitoring and Diagnostics
Monitoring is split between management landing zone services and post-deployment diagnostic wiring.
Source:
- landing-zones/management
- modules/monitoring
- modules/monitoring/diagnostic-settings
- main.tf post_deployment_diagnostics
| Resource | Module | Toggle |
|---|---|---|
| Log Analytics workspace | modules/monitoring/log-analytics | deploy_log_analytics |
| Action group | modules/monitoring/action-group | Management module |
| Alerts | modules/monitoring/alerts | Management module |
| Diagnostic settings | modules/monitoring/diagnostic-settings | Management and post-deployment |
| Workbooks | modules/monitoring/workbooks | deploy_workbooks |
| Connection Monitor | modules/monitoring/connection-monitor | deploy_connection_monitor |
| VNet flow logs | modules/monitoring/vnet-flow-logs | enable_vnet_flow_logs |
The diagnostic settings module can attach telemetry for:
- Azure Firewall
- VPN Gateway
- AKS
- SQL server
- SQL database
- Key Vault
- Storage account
- NSGs
Outputs source: modules/monitoring/diagnostic-settings/outputs.tf
Some IDs only exist after optional resources are created. The root module passes those actual IDs into a post-deployment diagnostic module.
Source: main.tf post_deployment_diagnostics module
The module can receive:
- AKS cluster ID from workload prod or dev
- SQL server ID
- SQL database ID
- Key Vault ID
- Storage account ID
- NSG resource IDs map
This avoids the previous pattern where monitoring was declared but important resource IDs were empty strings.
Alerts module: modules/monitoring/alerts
Alert outputs include:
- VM CPU
- VM memory
- VM disk
- VM network
- AKS CPU
- AKS memory
- AKS node count
- AKS pods
- SQL DTU
- SQL storage
- SQL connections
- Firewall health
- Firewall throughput
- VPN tunnel
- VPN bandwidth
Outputs source: modules/monitoring/alerts/outputs.tf
Profile examples:
| Profile | Retention | Daily quota |
|---|---|---|
cheap-lab |
30 days | 0.5 GB |
lab |
30 days | 2 GB |
dev |
30 days | 0.5 GB |
prod |
30 days | 5 GB |
Sources:
The repo supports VNet flow logs through modules/monitoring/vnet-flow-logs.
Related variables:
enable_vnet_flow_logsenable_nsg_flow_logsenable_traffic_analyticscreate_network_watchernetwork_watcher_name
For new builds, prefer VNet flow logs over NSG flow logs.
After apply:
- Confirm Log Analytics workspace exists.
- Confirm diagnostic settings exist for deployed optional resources.
- Confirm action group receivers are correct.
- Confirm alerts are enabled and scoped to existing resources.
- Confirm VNet flow logs are disabled in low-cost profiles unless needed.
- Confirm daily quota is appropriate for the lab profile.
| Resource family | Diagnostic owner | Expected sink |
|---|---|---|
| Firewall and VPN | Networking/platform owner | Log Analytics |
| Key Vault, SQL, Storage | Shared services owner | Log Analytics |
| AKS | Workload/platform owner | Log Analytics |
| NSGs and flow logs | Network operations owner | Storage and/or Log Analytics |
| Cost alerts | Subscription owner | Action group |
The goal is to avoid the false state where monitoring modules exist but deployed resources do not emit useful telemetry.
- Architecture Overview
- Full Environment Inventory
- Network Topology
- Shared Services
- Workloads
- Module Reference
- Security Model
- Security Operations
- Identity and Access
- Governance and Policy
- Production Readiness Review
- Monitoring and Diagnostics
- Operations Runbooks
- Azure Portal Validation Evidence
- Cost Management
- Disaster Recovery and Resilience