Fundamentação Teórica: Set Up Alert Rules, Action Groups, and Alert Processing Rules in Azure Monitor

1. Intuição Inicial

Imagine que você administra um datacenter físico. Você não fica olhando para os servidores 24 horas por dia. Em vez disso, você instala sensores: um sensor de temperatura que dispara uma sirene se o ar-condicionado falhar, um sensor de carga que aciona um alarme se o disco atingir 90% de uso, câmeras que alertam sobre movimentação suspeita fora do horário.

Alert Rules no Azure são esses sensores e condições de disparo. Você define: "quando a CPU da VM ficar acima de 85% por mais de 5 minutos, me notifique".

Action Groups são a lista de contatos e ações a executar quando o alarme dispara: enviar e-mail para a equipe de operações, mandar SMS para o gerente de plantão, chamar um webhook que abre um ticket no Jira automaticamente.

Alert Processing Rules são as políticas de silêncio e roteamento: "durante janelas de manutenção programada, não envie alertas", ou "todos os alertas de produção devem também acionar a equipe de segurança".

Juntos, esses três componentes formam o sistema completo de alertas do Azure.

2. Contexto

2.1 Os três pilares do sistema de alertas

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

2.2 Tipos de Alert Rules por fonte de dados

O Azure tem diferentes tipos de alert rules dependendo de onde os dados vêm:

Tipo	Fonte de dados	Latência	Exemplo de uso
Metric alerts	Azure Monitor Metrics	1-5 min	CPU > 85%, Storage > 90%
Log alerts	Log Analytics (KQL)	5-15 min	10+ falhas de login em 5 min
Activity log alerts	Azure Activity Log	5-10 min	VM deletada, NSG modificado
Service Health alerts	Azure Service Health	Variável	Incidentes na região, manutenção
Resource health alerts	Azure Resource Health	Variável	VM ficou indisponível

3. Construção dos Conceitos

3.1 Alert Rule: anatomia completa

Uma Alert Rule é composta por:

1. Scope (Escopo): O recurso ou conjunto de recursos monitorados. Pode ser uma VM, um Resource Group inteiro, ou uma Subscription.

2. Condition (Condição): O que está sendo medido e quando o alerta deve disparar. Define:

Signal: qual métrica, log ou atividade monitorar
Operator: maior que, menor que, igual a
Threshold: o valor que dispara o alerta
Aggregation: como os valores são combinados (Average, Maximum, etc.)
Evaluation period: janela de tempo dos dados avaliados
Frequency: com que frequência avaliar a condição

3. Action Group: Qual Action Group acionar quando a condição for satisfeita.

4. Alert Details: Nome, descrição, severidade e outras propriedades do alerta.

3.2 Severidade dos alertas

Nível	Nome	Uso típico
Sev 0	Critical	Falha crítica com impacto imediato em produção
Sev 1	Error	Problema sério que requer ação rápida
Sev 2	Warning	Condição preocupante que precisa de atenção
Sev 3	Informational	Informação relevante sem urgência
Sev 4	Verbose	Diagnóstico detalhado

3.3 Stateful vs Stateless alerts

Stateful (padrão para metric alerts): O alerta tem estados: Fired (disparado), Resolved (resolvido). Quando a condição deixa de ser verdadeira, o alerta é automaticamente resolvido e uma notificação de resolução é enviada.

Stateless (padrão para log alerts): Cada avaliação que satisfaz a condição dispara uma notificação, independentemente do estado anterior. Útil para eventos que não têm conceito de "resolvido" natural.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.4 Metric Alert: condições avançadas

Threshold estático: Valor fixo comparado com a métrica.

CPU Percentage > 85  (average, over 5 minutes)

Threshold dinâmico (Dynamic Thresholds): O Azure aprende o comportamento histórico da métrica e define automaticamente limiares baseados em desvios da normalidade. Útil quando o comportamento normal varia por hora do dia ou dia da semana.

Dimensões em metric alerts: Você pode criar um alerta que monitora uma métrica filtrada por dimensão. Exemplo: alerta para erro 500 em apenas uma região específica.

3.5 Log Alert: configuração da query KQL

Log alerts executam uma query KQL em intervalos regulares e disparam quando o resultado satisfaz uma condição:

Número de resultados: Alerta se a query retornar mais ou menos que X linhas.

SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(5m)

Configuração: "Se count > 10, disparar alerta"

Medida métrica: A query calcula um valor numérico por recurso/tempo, e o alerta dispara quando esse valor cruza um threshold.

Perf
| where CounterName == "% Processor Time"
| summarize AvgCPU = avg(CounterValue) by Computer
| where AvgCPU > 85

3.6 Action Groups: tipos de ação

Notificações:

Tipo	Descrição	Limitação
Email (Azure Resource Manager role)	Email para membros de uma RBAC role	Até 1.000 emails/hora
Email/SMS/Push/Voice	Email, SMS, notificação de app Azure, ligação	Limites por subscritor
Azure App Push	Notificação no app Azure mobile	Requer app instalado

Ações:

Tipo	Descrição	Quando usar
Automation Runbook	Executa um runbook PowerShell/Python	Remediação automática
Azure Function	Invoca uma Function App	Lógica customizada
Event Hub	Publica no Event Hub	Integração com streaming
ITSM	Abre ticket em ServiceNow, Cherwell	Gestão de incidentes
Logic App	Inicia um workflow Logic App	Orquestração complexa
Secure Webhook	Chama endpoint HTTPS com autenticação AAD	Sistemas externos
Webhook	Chama endpoint HTTPS	Integrações simples

3.7 Alert Processing Rules: o orquestrador

Alert Processing Rules atuam sobre alertas já disparados. Elas podem:

1. Suprimir notificações (Suppression): Silenciar notificações de alertas durante janelas de manutenção. O alerta ainda é disparado e registrado, mas as notificações não são enviadas.

2. Aplicar Action Group adicional: Adicionar um Action Group a alertas que correspondam a filtros definidos. Exemplo: todos os alertas de severidade 0 e 1 em produção devem acionar também o gestor via SMS.

Filtros disponíveis em Alert Processing Rules:

Subscription
Resource Group
Resource Type
Resource
Alert Rule
Severity
Monitor Condition (Fired/Resolved)
Alert Context

Agendamento: Podem ser configuradas para atuar sempre ou apenas em janelas de tempo específicas (ex: sábado e domingo das 22h às 06h para janelas de manutenção).

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

5.1 Metric Alert: comportamento do evaluation

Quando você configura um metric alert, dois parâmetros definem o comportamento:

Evaluation frequency (frequência): De quanto em quanto tempo a condição é verificada. Exemplo: a cada 5 minutos.

Aggregation granularity (janela): Qual período de dados é considerado em cada avaliação. Exemplo: janela de 15 minutos.

Se frequency = 5m e window = 15m: a cada 5 minutos, o Azure avalia os últimos 15 minutos de dados agregados.

Comportamento não óbvio: Um alerta com window = 15m pode levar até 20 minutos para disparar após uma condição ser atingida (15 min da janela + até 5 min da frequência de avaliação + latência de coleta de métricas). Para alertas críticos que precisam disparar rápido, use window = 5m e frequency = 1m.

5.2 Supressão vs Desabilitar alerta

Há uma distinção importante:

Suprimir via Alert Processing Rule: O alerta ainda é criado e registrado no histórico. As notificações são suprimidas. Quando a janela de supressão termina, alertas que continuam disparando voltam a notificar.

Desabilitar a Alert Rule: A condição não é mais avaliada. Não há registro de alertas durante o período desabilitado. Não recomendado para manutenções porque você perde visibilidade.

6. Formas de Implementação

6.1 Portal Azure

Quando usar: Criação inicial, exploração de opções disponíveis, troubleshooting visual.

Criando metric alert: Azure Monitor > Alerts > + Create > Alert rule

Criando Action Group: Azure Monitor > Alerts > Action groups > + Create

Criando Alert Processing Rule: Azure Monitor > Alerts > Alert processing rules > + Create

6.2 Azure CLI

Criando Action Group:

az monitor action-group create \
  --resource-group myRG \
  --name "ops-team-ag" \
  --short-name "OpsTeam" \
  --email-receiver name="OnCall" email-address="oncall@company.com" use-common-alert-schema=true \
  --sms-receiver name="Manager" country-code="55" phone-number="11999999999" \
  --webhook-receiver name="PagerDuty" service-uri="https://events.pagerduty.com/integration/xxx/enqueue" use-common-alert-schema=true

Criando Metric Alert:

az monitor metrics alert create \
  --resource-group myRG \
  --name "High-CPU-Alert" \
  --scopes <vm-resource-id> \
  --condition "avg Percentage CPU > 85" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --severity 2 \
  --action-group <action-group-id> \
  --description "CPU media acima de 85% por 5 minutos" \
  --auto-mitigate true

Criando Log Alert:

az monitor scheduled-query alert create \
  --resource-group myRG \
  --name "Failed-Login-Alert" \
  --scopes <workspace-resource-id> \
  --condition-query "SecurityEvent | where EventID == 4625 | where TimeGenerated > ago(5m) | summarize count()" \
  --condition-operator "GreaterThan" \
  --condition-threshold 10 \
  --evaluation-frequency 5m \
  --window-size 5m \
  --severity 1 \
  --action-group <action-group-id>

Criando Activity Log Alert:

az monitor activity-log alert create \
  --resource-group myRG \
  --name "VM-Delete-Alert" \
  --scope /subscriptions/<sub-id> \
  --condition category=Administrative and operationName=Microsoft.Compute/virtualMachines/delete \
  --action-group <action-group-id>

Criando Alert Processing Rule (supressão de manutenção):

az monitor alert-processing-rule create \
  --resource-group myRG \
  --name "Weekend-Maintenance" \
  --rule-type Suppression \
  --scopes /subscriptions/<sub-id>/resourceGroups/production-rg \
  --filter-severity Sev0 Sev1 Sev2 \
  --schedule-recurrence-type Weekly \
  --schedule-recurrence Saturday Sunday \
  --schedule-start-datetime "2025-01-01 22:00:00" \
  --schedule-end-datetime "2025-01-01 06:00:00"

6.3 Bicep

// Action Group
resource actionGroup 'Microsoft.Insights/actionGroups@2023-01-01' = {
  name: 'ops-team-ag'
  location: 'global'
  properties: {
    groupShortName: 'OpsTeam'
    enabled: true
    emailReceivers: [
      {
        name: 'OnCall'
        emailAddress: 'oncall@company.com'
        useCommonAlertSchema: true
      }
    ]
    smsReceivers: [
      {
        name: 'Manager'
        countryCode: '55'
        phoneNumber: '11999999999'
      }
    ]
    webhookReceivers: [
      {
        name: 'Automation'
        serviceUri: 'https://prod.webhook.office.com/...'
        useCommonAlertSchema: true
      }
    ]
  }
}

// Metric Alert
resource cpuAlert 'Microsoft.Insights/metricAlerts@2018-03-01' = {
  name: 'High-CPU-Alert'
  location: 'global'
  properties: {
    description: 'CPU media acima de 85% por 5 minutos'
    severity: 2
    enabled: true
    scopes: [vm.id]
    evaluationFrequency: 'PT1M'
    windowSize: 'PT5M'
    criteria: {
      'odata.type': 'Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria'
      allOf: [
        {
          name: 'HighCPU'
          metricName: 'Percentage CPU'
          operator: 'GreaterThan'
          threshold: 85
          timeAggregation: 'Average'
          criterionType: 'StaticThresholdCriterion'
        }
      ]
    }
    autoMitigate: true
    actions: [
      {
        actionGroupId: actionGroup.id
      }
    ]
  }
}

// Alert Processing Rule (supressao de manutencao)
resource maintenanceRule 'Microsoft.AlertsManagement/actionRules@2021-08-08' = {
  name: 'Weekend-Maintenance'
  location: 'global'
  properties: {
    scopes: [resourceGroup().id]
    conditions: [
      {
        field: 'Severity'
        operator: 'Equals'
        values: ['sev0', 'sev1', 'sev2']
      }
    ]
    actions: [
      {
        actionType: 'RemoveAllActionGroups'
      }
    ]
    schedule: {
      recurrences: [
        {
          recurrenceType: 'Weekly'
          daysOfWeek: ['Saturday', 'Sunday']
          startTime: '22:00:00'
          endTime: '06:00:00'
        }
      ]
    }
    enabled: true
  }
}

7. Controle e Segurança

7.1 Permissões necessárias

Operação	Role mínima
Criar/editar Alert Rules	Monitoring Contributor
Criar/editar Action Groups	Monitoring Contributor
Criar/editar Alert Processing Rules	Monitoring Contributor
Apenas visualizar alertas disparados	Monitoring Reader
Reconhecer (acknowledge) alertas	Monitoring Contributor

7.2 Common Alert Schema

O Common Alert Schema é um formato JSON padronizado para notificações de todos os tipos de alerta (metric, log, activity log). Quando habilitado no Action Group, todos os webhooks e Logic Apps recebem a mesma estrutura, independentemente do tipo de alerta.

{
  "schemaId": "azureMonitorCommonAlertSchema",
  "data": {
    "essentials": {
      "alertId": "/subscriptions/.../alerts/...",
      "alertRule": "High-CPU-Alert",
      "severity": "Sev2",
      "signalType": "Metric",
      "monitorCondition": "Fired",
      "monitoringService": "Platform",
      "alertTargetIDs": ["/subscriptions/.../virtualMachines/myVM"],
      "firedDateTime": "2025-01-15T14:32:00Z"
    },
    "alertContext": {
      "properties": {},
      "conditionType": "SingleResourceMultipleMetricCriteria",
      "condition": {
        "windowSize": "PT5M",
        "allOf": [...]
      }
    }
  }
}

Use Common Alert Schema sempre que possível. Simplifica enormemente o processamento em Logic Apps e webhooks.

7.3 Rate limits de notificação

Canal	Limite
Email	100 emails/hora por Action Group
SMS	1 SMS a cada 5 minutos por receptor
Voice	1 ligação a cada 5 minutos por receptor
Webhook	Sem limite explícito (depende do endpoint)
Azure Function	Sem limite explícito

Comportamento importante: Se múltiplos alertas disparam ao mesmo tempo e há muitos receptores de email, o Azure aplica rate limiting silenciosamente. Nem todas as notificações chegam imediatamente. Para cenários de alta carga, use webhook ou Event Hub como canal primário.

8. Tomada de Decisão

8.1 Qual tipo de alert usar para cada cenário

Cenário	Tipo de alert	Motivo
CPU da VM > 85%	Metric Alert	Métrica de plataforma com threshold fixo
Padrão de CPU anômalo (sem threshold conhecido)	Metric Alert com Dynamic Threshold	Azure aprende o padrão histórico
10+ falhas de login em 5 min	Log Alert	Requer query KQL sobre logs
VM deletada (auditoria)	Activity Log Alert	Evento de plano de controle
Região Azure com incidente	Service Health Alert	Saúde do serviço Azure
Disco OS com mais de 90%	Metric Alert (Guest metrics)	Requer Azure Monitor Agent na VM

8.2 Quando usar Alert Processing Rules vs configurar Action Group na Alert Rule

Situação	Abordagem	Motivo
Janela de manutenção recorrente	Alert Processing Rule (Suppression)	Configuração centralizada, não precisa modificar cada Alert Rule
Todos os alertas de prod devem cc o gestor	Alert Processing Rule (Add Action Group)	Evita duplicar o Action Group em cada Alert Rule
Alerta específico com ação específica	Action Group diretamente na Alert Rule	Mais simples, sem necessidade de camada adicional
Silenciar apenas durante implantação específica	Alert Processing Rule com janela única	Flexibilidade sem modificar Alert Rules

8.3 Frequency e Window Size: equilibrando velocidade e custo

Requisito	Frequency	Window	Consideração
Detecção ultra-rápida (crítico)	1 min	5 min	Maior custo de avaliação
Detecção moderada (padrão)	5 min	15 min	Equilíbrio custo/velocidade
Alerta de tendência (não urgente)	15 min	1 hora	Menor custo, mais suavizado

9. Boas Práticas

Crie Action Groups reutilizáveis separados por time (ops-team, security-team, management) e referencie-os em múltiplas Alert Rules em vez de criar um Action Group por alerta.
Use Common Alert Schema em todos os webhooks e Logic Apps para simplificar o processamento.
Separe alertas por severidade e configure Action Groups diferentes: Sev0/Sev1 aciona SMS + email imediato; Sev2/Sev3 envia apenas email.
Configure auto-mitigate = true em metric alerts para receber notificação de resolução automática quando a condição não é mais satisfeita.
Use Alert Processing Rules para manutenção em vez de desabilitar Alert Rules. O alerta continua sendo avaliado e registrado.
Documente o significado de cada alerta na descrição da Alert Rule: o que significa quando dispara, qual a ação esperada, qual o runbook de resposta.
Agrupe alertas relacionados usando o campo "Alert Rule Name" como filtro em Alert Processing Rules para aplicar lógica consistente.
Teste Action Groups usando o botão "Test" no portal antes de confiar neles em produção. Verifique se emails chegam, se webhooks respondem com 200.
Configure alertas de saúde de serviço (Service Health) para receber notificações de incidentes e manutenção do Azure nas regiões que você usa.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Alerta disparando constantemente (alert fatigue)	Threshold muito sensível ou window muito pequena	Ajustar threshold; usar dynamic thresholds
Não recebeu notificação de alerta crítico	Rate limiting de email ativo	Usar webhook ou Azure Function como canal primário para Sev0/Sev1
Alerta não dispara durante incidente real	Alert Rule desabilitada ou threshold muito alto	Testar regularmente com Test Action Group
Alerta dispara durante manutenção	Sem Alert Processing Rule de supressão	Criar APR com janela de manutenção
Log alert não dispara	Query KQL incorreta ou dados ainda em trânsito	Testar query separadamente no Log Analytics; verificar latência de ingestão
Muitos alertas duplicados	Frequência baixa + window grande criando overlaps	Ajustar frequency e window; habilitar stateful
Action Group não aciona webhook	Endpoint com certificado inválido ou timeout	Usar Secure Webhook com autenticação AAD para robustez
Alert Processing Rule não suprime	Filtros incorretos (severidade, scope)	Verificar se os filtros correspondem exatamente ao alerta disparado

11. Operação e Manutenção

11.1 Visualizando alertas disparados

# Listar alertas ativos na assinatura
az monitor alert list \
  --resource-group myRG \
  --output table

# Ver histórico de alertas (últimas 24h)
az monitor alert list \
  --state "all" \
  --time-range 1d \
  --output table

No portal: Azure Monitor > Alerts > Alerts (preview) mostra estado atual de todos os alertas.

11.2 Reconhecendo (acknowledging) alertas

Alertas podem ter estado gerenciado manualmente:

Fired: Condição ativa, notificação enviada
Acknowledged: Alguém reconheceu o alerta (está sendo investigado)
Resolved: Condição não é mais verdadeira

az monitor alert update \
  --ids <alert-resource-id> \
  --status Acknowledged

11.3 Testando Action Groups

# Enviar notificação de teste para um Action Group
az monitor action-group test \
  --resource-group myRG \
  --action-group-name "ops-team-ag" \
  --alert-type servicehealth

Verifique se:

Email chegou na caixa de entrada (não spam)
SMS foi recebido
Webhook retornou 200 OK
Azure Function foi invocada

11.4 Limites importantes

Recurso	Limite
Alert Rules por assinatura	5.000
Action Groups por assinatura	2.000
Receptores por Action Group	10 por tipo
Alert Processing Rules por assinatura	1.000
Retenção de histórico de alertas	30 dias
Frequência mínima de metric alert	1 minuto
Frequência mínima de log alert	5 minutos

12. Integração e Automação

12.1 Remediação automática com Automation Runbook

Configure um Action Group que chama um runbook para auto-remediar:

# Runbook: restartar VM automaticamente se CPU > threshold
param(
    [Parameter(Mandatory=$true)]
    [string]$vmName,
    [string]$resourceGroup
)

Connect-AzAccount -Identity

Write-Output "Reiniciando VM $vmName em resposta a alerta de CPU alta"
Restart-AzVM -ResourceGroupName $resourceGroup -Name $vmName
Write-Output "VM reiniciada com sucesso"

12.2 Integração com Microsoft Teams via Logic App

Crie um Logic App com trigger HTTP
Configure o Logic App para postar mensagem no Teams
Adicione o endpoint do Logic App como Webhook no Action Group

O payload do Common Alert Schema permite criar mensagens ricas no Teams com todos os detalhes do alerta.

12.3 Azure Policy para garantir cobertura de alertas

# Policy: garantir que todas as VMs tenham alert rule de CPU
az policy assignment create \
  --name "vm-cpu-alert-required" \
  --policy "<policy-definition-id>" \
  --scope "/subscriptions/<sub-id>"

Policies DeployIfNotExists podem criar automaticamente Alert Rules em novos recursos.

13. Resumo Final

Conceitos essenciais:

Alert Rule define a condição de disparo: qual sinal monitorar (métrica, log, activity log), qual threshold, em qual janela de tempo e com qual frequência.
Action Group define o que acontece quando o alerta dispara: notificações (email, SMS, push) e ações (runbook, function, webhook, ITSM).
Alert Processing Rule modifica o comportamento de alertas já disparados: suprime notificações em janelas de manutenção ou adiciona Action Groups adicionais baseado em filtros.

Diferenças críticas:

Metric Alert vs Log Alert: Metric opera sobre valores numéricos em tempo quase real (1-5 min). Log Alert executa query KQL sobre logs com maior latência (5-15 min).
Stateful vs Stateless: Stateful dispara uma vez ao atingir a condição e resolve automaticamente. Stateless dispara a cada avaliação que satisfaz a condição.
Suprimir vs Desabilitar: Suprimir (via APR) mantém o alerta sendo avaliado e registrado. Desabilitar a Alert Rule para totalmente a avaliação.
Frequency vs Window: Frequency é de quanto em quanto tempo a condição é avaliada. Window é o período de dados considerado em cada avaliação.

O que precisa ser lembrado:

Um alerta pode levar até window + frequency + latência de coleta para disparar após a condição ser atingida.
Action Groups têm rate limits: 100 emails/hora, 1 SMS a cada 5 minutos por receptor.
Use Common Alert Schema em webhooks e Logic Apps para receber formato padronizado independente do tipo de alerta.
Alert Processing Rules filtram por subscription, resource group, resource type, severidade, status e nome de alert rule.
Para manutenções, use Alert Processing Rules com janela de tempo em vez de desabilitar Alert Rules.
Teste Action Groups com o botão "Test" antes de confiar neles em produção.
O histórico de alertas é retido por 30 dias no portal Azure Monitor.

1. Intuição Inicial​

2. Contexto​

2.1 Os três pilares do sistema de alertas​

2.2 Tipos de Alert Rules por fonte de dados​

3. Construção dos Conceitos​

3.1 Alert Rule: anatomia completa​

3.2 Severidade dos alertas​

3.3 Stateful vs Stateless alerts​

3.4 Metric Alert: condições avançadas​

3.5 Log Alert: configuração da query KQL​

3.6 Action Groups: tipos de ação​

3.7 Alert Processing Rules: o orquestrador​

4. Visão Estrutural​

5. Funcionamento na Prática​

5.1 Metric Alert: comportamento do evaluation​

5.2 Supressão vs Desabilitar alerta​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Bicep​

7. Controle e Segurança​

7.1 Permissões necessárias​

7.2 Common Alert Schema​

7.3 Rate limits de notificação​

8. Tomada de Decisão​

8.1 Qual tipo de alert usar para cada cenário​

8.2 Quando usar Alert Processing Rules vs configurar Action Group na Alert Rule​

8.3 Frequency e Window Size: equilibrando velocidade e custo​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

11.1 Visualizando alertas disparados​

11.2 Reconhecendo (acknowledging) alertas​

11.3 Testando Action Groups​

11.4 Limites importantes​

12. Integração e Automação​

12.1 Remediação automática com Automation Runbook​

12.2 Integração com Microsoft Teams via Logic App​

12.3 Azure Policy para garantir cobertura de alertas​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 Os três pilares do sistema de alertas

2.2 Tipos de Alert Rules por fonte de dados

3. Construção dos Conceitos

3.1 Alert Rule: anatomia completa

3.2 Severidade dos alertas

3.3 Stateful vs Stateless alerts

3.4 Metric Alert: condições avançadas

3.5 Log Alert: configuração da query KQL

3.6 Action Groups: tipos de ação

3.7 Alert Processing Rules: o orquestrador

4. Visão Estrutural

5. Funcionamento na Prática

5.1 Metric Alert: comportamento do evaluation

5.2 Supressão vs Desabilitar alerta

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Bicep

7. Controle e Segurança

7.1 Permissões necessárias

7.2 Common Alert Schema

7.3 Rate limits de notificação

8. Tomada de Decisão

8.1 Qual tipo de alert usar para cada cenário

8.2 Quando usar Alert Processing Rules vs configurar Action Group na Alert Rule

8.3 Frequency e Window Size: equilibrando velocidade e custo

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Visualizando alertas disparados

11.2 Reconhecendo (acknowledging) alertas

11.3 Testando Action Groups

11.4 Limites importantes

12. Integração e Automação

12.1 Remediação automática com Automation Runbook

12.2 Integração com Microsoft Teams via Logic App

12.3 Azure Policy para garantir cobertura de alertas

13. Resumo Final