Monitoramento do DR no Azure com Azure Monitor

Este é o artigo final da série: a camada de observabilidade que garante que você saiba o estado do seu DR a qualquer momento — não apenas durante os drills. O artigo configura Log Analytics Workspaces em ambas as regiões, dois Action Groups (crítico e aviso), três alertas essenciais baseados em KQL cobrindo ASR, Storage geo-replicado e AKS, e dois Workbooks consolidando visibilidade multi-região em um painel único. Ao final, você tem um dashboard operacional do DR que dispara alertas automaticamente quando a saúde da replicação cai ou o lag de storage excede o RPO definido.

Sumário

• Arquitetura de monitoramento
• Pré-requisitos
• Passo 1 — Log Analytics Workspaces
• Passo 2 — Action Groups
• Passo 3 — Alertas críticos com KQL
• Passo 4 — Workbooks de DR
• Passo 5 — Grafana (opcional)
• Consultas KQL úteis para o DR
• Troubleshooting
• Conclusão da série

Arquitetura de monitoramento

A estratégia de monitoramento do lab usa dois Log Analytics Workspaces — um por região — para evitar que a indisponibilidade da região primária também derrube o sistema de monitoramento. Os alertas são definidos com escopo nos workspaces de ambas as regiões, e os Action Groups ficam centralizados no Resource Group de network de Brazil South:

Componente	Recurso	Resource Group
Log Analytics BRS	law-blog-castilho-brazilsouth	rg-blog-castilho-network-brazilsouth
Log Analytics EUS	law-blog-castilho-eastus	rg-blog-castilho-network-eastus
Action Group Crítico	ag-critico-blog-castilho	rg-blog-castilho-network-brazilsouth
Action Group Aviso	ag-aviso-blog-castilho	rg-blog-castilho-network-brazilsouth
Alerta ASR replicação	asr-replication-unhealthy	Severity 0 — avalia a cada 5 min
Alerta Storage lag	storage-replication-lag-5min	Severity 0 — avalia a cada 5 min
Alerta AKS nodes	aks-node-not-ready	Severity 1 — avalia a cada 2 min
Workbooks	dr-overview, replication-health	rg-blog-castilho-network-brazilsouth

Pré-requisitos

• Resource Groups rg-blog-castilho-network-brazilsouth e rg-blog-castilho-network-eastus existentes (Art. 02)
• Azure CLI autenticado com permissões de Contributor
• Terraform ≥ 1.5 com backend Azure Storage configurado
• Endereço de email para receber alertas

Passo 1 — Log Analytics Workspaces

O Terraform em scripts/art-13-monitoramento/law-blog-castilho-brazilsouth/ cria o workspace de Brazil South com SKU PerGB2018 e retenção configurável via variável. O workspace de East US é idêntico, apontando para o Resource Group de network-eastus:

resource "azurerm_log_analytics_workspace" "this" {
  name                = "law-blog-castilho-brazilsouth"
  resource_group_name = data.azurerm_resource_group.this.name
  location            = data.azurerm_resource_group.this.location
  sku                 = "PerGB2018"
  retention_in_days   = var.retention_days  # default: 30
  tags                = var.tags
}

Para aplicar os dois workspaces:

SUBSCRIPTION_ID=""

# Brazil South
cd scripts/art-13-monitoramento/law-blog-castilho-brazilsouth
terraform init -backend-config=backend.hcl
terraform apply -var="subscription_id=$SUBSCRIPTION_ID"

# East US
cd ../law-blog-castilho-eastus
terraform init -backend-config=backend.hcl
terraform apply -var="subscription_id=$SUBSCRIPTION_ID"

Após a criação, os recursos Azure precisam ser configurados para enviar diagnósticos para os workspaces. Para o RSV (Art. 07), habilite o envio de logs via portal: RSV → Configurações de diagnóstico → + Adicionar configuração de diagnóstico → selecionar AzureSiteRecovery → enviar para o workspace de East US. Para o AKS (Art. 09), o Container Insights pode ser habilitado via az aks enable-addons --addons monitoring --workspace-resource-id.

Passo 2 — Action Groups

O Terraform em scripts/art-13-monitoramento/alerts-blog-castilho/ cria dois Action Groups com diferentes níveis de urgência. O grupo ag-critico-blog-castilho notifica por email e opcionalmente por Teams webhook. O grupo ag-aviso-blog-castilho notifica apenas por email:

resource "azurerm_monitor_action_group" "critico" {
  name                = "ag-critico-blog-castilho"
  resource_group_name = data.azurerm_resource_group.network_brs.name
  short_name          = "ag-critico"
  tags                = var.tags

  email_receiver {
    name                    = "time-ops"
    email_address           = var.alert_email
    use_common_alert_schema = true
  }

  dynamic "webhook_receiver" {
    for_each = var.teams_webhook_uri != "" ? [1] : []
    content {
      name                    = "teams"
      service_uri             = var.teams_webhook_uri
      use_common_alert_schema = true
    }
  }
}

resource "azurerm_monitor_action_group" "aviso" {
  name                = "ag-aviso-blog-castilho"
  resource_group_name = data.azurerm_resource_group.network_brs.name
  short_name          = "ag-aviso"
  tags                = var.tags

  email_receiver {
    name          = "time-ops"
    email_address = var.alert_email
    use_common_alert_schema = true
  }
}

O bloco dynamic "webhook_receiver" só cria o receiver do Teams se a variável teams_webhook_uri não estiver vazia — isso evita erro no apply quando o webhook ainda não foi configurado. Para conectar com o canal Teams da equipe, passe a URL do webhook do conector Incoming Webhook via variável de ambiente:

terraform apply \
  -var="subscription_id=$SUBSCRIPTION_ID" \
  -var="alert_email=" \
  -var="teams_webhook_uri=$TEAMS_WEBHOOK_URI"

Passo 3 — Alertas críticos com KQL

O mesmo Terraform cria três alertas do tipo azurerm_monitor_scheduled_query_rules_alert_v2 — a versão mais recente das Scheduled Query Rules que suporta avaliação de múltiplos períodos e dimensões. Cada alerta usa uma query KQL diferente:

Alerta 1 — ASR Replication Unhealthy (Severity 0 — Crítico)

Avaliado a cada 5 minutos com janela de 15 minutos no workspace de East US. Dispara quando qualquer VM tem ReplicationHealthStatus diferente de Normal:

AzureDiagnostics
| where Category == "AzureSiteRecoveryReplicationStats"
| where ReplicationHealthStatus_s != "Normal"
| summarize count() by Resource

Alerta 2 — Storage Replication Lag > 5min (Severity 0 — Crítico)

Avaliado a cada 5 minutos com janela de 10 minutos no workspace de Brazil South. Dispara quando o lag de geo-replicação da Storage Account excede 300 segundos (5 minutos = RPO objetivo):

AzureMetrics
| where MetricName == "GeoReplicationLag"
| where Average > 300

Alerta 3 — AKS Node Not Ready (Severity 1 — Alto)

Avaliado a cada 2 minutos com janela de 5 minutos. Dispara se qualquer nó do AKS entrar em estado NotReady por dois períodos consecutivos — evitando falsos positivos de reinicializações normais:

KubeNodeInventory
| where Status == "NotReady"
| summarize count() by Computer

O critério de minimum_failing_periods_to_trigger_alert = 1 nos alertas de ASR e Storage significa que uma única avaliação com resultado positivo já dispara o alerta — é o comportamento correto para situações de DR onde cada minuto conta. Para o AKS, o valor é 2 (dois períodos consecutivos) para evitar alertas de nós que reiniciam brevemente durante atualizações do node pool.

Passo 4 — Workbooks de DR

Os Workbooks são dashboards interativos do Azure Monitor que combinam queries KQL, métricas e texto em um único painel. A pasta scripts/art-13-monitoramento/workbooks/ contém dois arquivos JSON que podem ser importados diretamente no portal:

Workbook	Conteúdo
dr-overview.json	Visão consolidada do DR: estado de replicação ASR, lag do Storage, nós do AKS por região, últimos alertas disparados
replication-health.json	Detalhamento da saúde de replicação: histórico de ReplicationHealthStatus por VM, recovery points disponíveis, tempo desde o último sync

Para importar um Workbook no portal Azure:

# Via CLI — criar workbook a partir do JSON
WORKBOOK_CONTENT=$(cat scripts/art-13-monitoramento/workbooks/dr-overview.json)

az monitor app-insights workbook create \
  --resource-group rg-blog-castilho-network-brazilsouth \
  --name "DR Overview" \
  --category workbook \
  --serialized-data "$WORKBOOK_CONTENT" \
  --location brazilsouth

Alternativamente, importe diretamente no portal: Azure Monitor → Workbooks → + Novo → Editor avançado → colar o JSON → Aplicar → Salvar. O Workbook fica disponível no Resource Group especificado e pode ser fixado no Azure Dashboard para acesso rápido durante incidentes.

Passo 5 — Grafana (opcional)

A pasta scripts/art-13-monitoramento/grafana/ contém dashboards JSON e manifests Kubernetes para deploy do Grafana no AKS BRS com o plugin Azure Monitor como datasource. Um Service Principal dedicado (sp-grafana-blog-castilho) com o papel Monitoring Reader e Log Analytics Reader é criado para autenticar o Grafana na API do Azure Monitor — as credenciais ficam no Key Vault kv-blog-castilho criado no Art. 11.

# Criar o Service Principal e salvar as credenciais no Key Vault
az ad sp create-for-rbac \
  --name "sp-grafana-blog-castilho" \
  --role "Monitoring Reader" \
  --scopes "/subscriptions/$AZURE_SUBSCRIPTION_ID"

az role assignment create \
  --assignee "sp-grafana-blog-castilho" \
  --role "Log Analytics Reader" \
  --scope "/subscriptions/$AZURE_SUBSCRIPTION_ID"

# Salvar credenciais no Key Vault (nunca em arquivos versionados)
az keyvault secret set --vault-name kv-blog-castilho \
  --name "grafana-client-id" --value "<APP_ID_DO_SP>"
az keyvault secret set --vault-name kv-blog-castilho \
  --name "grafana-client-secret" --value "<PASSWORD_DO_SP>"

Com as credenciais no Key Vault, o script grafana/k8s/deploy-grafana.sh lê os segredos e aplica todos os manifests no namespace monitoring do AKS BRS — Namespace, Secret, ConfigMaps (datasource + dashboards), PVC (2Gi) e Deployment (1 réplica, grafana:11.1.0):

# Deploy do Grafana no AKS BRS (lê credenciais do Key Vault automaticamente)
bash scripts/art-13-monitoramento/grafana/k8s/deploy-grafana.sh

# Verificar pod e endpoint
kubectl get pods -n monitoring
kubectl get svc grafana -n monitoring

# Output esperado:
# NAME                       READY   STATUS    RESTARTS
# grafana-xxxxxxxxx-xxxxx    1/1     Running   0
#
# NAME      TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)
# grafana   LoadBalancer   172.16.x.x      <LB_IP>       80:xxxxx/TCP
#
# Acessar em http://<LB_IP>  (credenciais padrão: admin / admin)

O Grafana Managed do Azure (Preview) também pode ser usado — ele se integra nativamente com Log Analytics e Azure Monitor sem precisar configurar datasources manualmente. Para ambientes de produção com múltiplas equipes, o Azure Managed Grafana é preferível por ter RBAC integrado com o Azure AD.

Consultas KQL úteis para o DR

Além dos alertas automáticos, estas queries KQL são úteis para investigação manual durante e após um incidente:

Histórico de saúde de replicação das últimas 24h:

AzureDiagnostics
| where Category == "AzureSiteRecoveryReplicationStats"
| where TimeGenerated > ago(24h)
| project TimeGenerated, Resource, ReplicationHealthStatus_s, RecoveryPointObjective_d
| order by TimeGenerated desc

Eventos de failover e recovery no ASR:

AzureDiagnostics
| where Category == "AzureSiteRecoveryEvents"
| where EventName_s contains "Failover" or EventName_s contains "Recovery"
| project TimeGenerated, EventName_s, Description_s, VmName_s
| order by TimeGenerated desc
| take 20

Pods do AKS com restart excessivo (possível impacto no DR):

KubePodInventory
| where TimeGenerated > ago(1h)
| where RestartCount > 3
| summarize MaxRestarts = max(RestartCount) by PodName, Namespace, Computer
| order by MaxRestarts desc

Lag de geo-replicação do Storage nas últimas 4h:

AzureMetrics
| where MetricName == "GeoReplicationLag"
| where TimeGenerated > ago(4h)
| summarize AvgLagSeconds = avg(Average), MaxLagSeconds = max(Maximum) by bin(TimeGenerated, 5m), Resource
| order by TimeGenerated desc

Troubleshooting

Problema	Causa	Solução
Alerta ASR nunca dispara mesmo com replicação unhealthy	O RSV não está enviando diagnósticos para o Log Analytics	Verificar as Configurações de diagnóstico no RSV — a categoria AzureSiteRecoveryReplicationStats deve estar habilitada e apontando para o workspace de East US
Query KQL retorna zero resultados para KubeNodeInventory	O Container Insights não foi habilitado no AKS	Habilitar: az aks enable-addons --addons monitoring --resource-group rg-blog-castilho-workload-brazilsouth --name aks-blog-castilho-brazilsouth --workspace-resource-id <LAW_ID>
Email de alerta não chega	Spam filter ou Action Group sem permissão para enviar	Verificar caixa de spam. Confirmar o email no portal: Monitor → Action Groups → ag-critico → Email receivers → verificar endereço
Workbook sem dados após importação	O datasource do Workbook aponta para o workspace errado	Editar o Workbook: + Editar → selecionar o datasource correto no topo e atualizar o Resource Group e workspace nas queries
Alerta de Storage lag disparando constantemente	Threshold de 300s muito baixo para a largura de banda disponível	Aumentar o threshold para 600s (10 min) ou investigar throttling na Storage Account. O lag normal em RA-GZRS varia de segundos a poucos minutos dependendo do volume de escrita

Conclusão da série

Esta série de 13 artigos construiu um ambiente completo de Disaster Recovery no Azure do zero — desde o planejamento da Landing Zone Hub-Spoke até o monitoramento contínuo da saúde de replicação. Cada artigo adicionou uma camada que depende das anteriores, resultando em um lab funcional com:

• Rede multi-região: Hub-Spoke em Brazil South e East US com Firewall, NSGs, Bastion e DNS privado
• Roteamento global: Front Door com WAF e Traffic Manager para failover automático de tráfego
• Proteção de VMs: Azure Site Recovery com replicação contínua e RPO de 5 minutos
• Dados resilientes: Storage Account RA-GZRS com Private Endpoints em ambas as regiões
• Containers multi-região: AKS em Brazil South e East US com ACR geo-replicado e Velero para backup de namespaces
• Automação de failover: Runbooks PowerShell no Azure Automation com webhook de acionamento
• Validação periódica: Drills de DR com Test Failover sem impacto em produção e relatório de RTO/RPO
• Observabilidade: Log Analytics, alertas KQL e Workbooks consolidados

O próximo passo natural é adaptar este lab ao seu ambiente real: substituir os recursos fictícios pelos nomes do seu ambiente, ajustar os objetivos de RTO e RPO com base nas suas necessidades de negócio, e integrar o webhook de failover com o seu sistema de on-call. O código Terraform de todos os artigos está disponível na pasta scripts/ deste repositório — prontos para servir de base para o seu ambiente de produção.

Interessado em saber mais sobre artigos relacionados ao Microsoft Azure CLIQUE AQUI

🚀 Vamos nos conectar?

Não perca nenhuma oportunidade! Cadastre-se nas minhas redes e no canal do YouTube para receber conteúdos de TI, Cloud, Azure, Kubernetes e DevOps em primeira mão.

📺 YouTube: Jefferson Castilho – MVP💼 LinkedIn: Jefferson Castilho 👥 Facebook: Jefferson Castilho

Dica: No Facebook, todos os artigos do blog são publicados automaticamente. Vale a pena curtir!

---

💬 Dúvidas ou Problemas?

Com o intuito de ajudar a comunidade, caso você tenha dúvidas ou encontre problemas na execução dos comandos deste artigo, deixe um comentário abaixo. Responderei o mais breve possível!

Muito obrigado pela visita e até o próximo post!

Jefferson Castilho Especialista em Cloud & DevOps.

---

Este guia técnico é exclusivo do Blog do Castilho. Explore nossa para mais conteúdos sobre IA e Cloud.