Como implementar alertas inteligentes com Alertmanager e PagerDuty

1. Fundamentos da arquitetura de alertas inteligentes

Alertas inteligentes representam a evolução dos sistemas tradicionais de monitoramento, substituindo notificações brutas por um fluxo contextualizado e livre de ruído. Em uma arquitetura moderna, o Prometheus coleta métricas, o Alertmanager atua como cérebro agregador e o PagerDuty fornece a camada de escalonamento humano. O objetivo central é garantir que cada notificação recebida por um engenheiro seja relevante, acionável e não redundante.

Os três pilares dos alertas inteligentes são:

  • Redução de ruído: eliminar alertas duplicados ou irrelevantes
  • Agrupamento: consolidar múltiplos eventos relacionados em um único incidente
  • Supressão: silenciar temporariamente alertas conhecidos ou de baixa prioridade

2. Configuração avançada do Alertmanager para redução de ruído

O coração da redução de ruído está nas diretivas de agrupamento. A configuração abaixo demonstra como consolidar alertas por serviço e severidade:

route:
  group_by: ['service', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'pagerduty-critical'

O group_wait de 30 segundos acumula alertas que chegam simultaneamente, enquanto o group_interval de 5 minutos evita renotificações para o mesmo grupo. O repeat_interval de 4 horas garante que um alerta não resolvido seja reenviado apenas após esse período.

Para inibidores, use inhibit_rules para suprimir alertas menos críticos quando um alerta de maior severidade está ativo:

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['service', 'region']

Isso impede que alertas warning sejam notificados se um critical já estiver disparado para o mesmo serviço e região. Silenciamentos temporários podem ser adicionados via API ou interface web do Alertmanager, usando matchers como:

- matchers:
    - alertname = "HighCpuUsage"
    - service = "database"

3. Roteamento de alertas com base em criticidade e contexto

A estrutura de routes no Alertmanager permite encaminhamentos diferenciais. Um exemplo prático:

route:
  receiver: 'default'
  routes:
    - match:
        severity: 'critical'
      receiver: 'pagerduty-critical'
      continue: true
    - match:
        severity: 'warning'
      receiver: 'slack-warnings'
    - match:
        service: 'monitoring'
      receiver: 'email-team'

Neste cenário:

  • Alertas critical vão para PagerDuty e também continuam para outras rotas
  • Alertas warning vão apenas para Slack
  • Alertas do serviço monitoring são enviados por e-mail

A rota padrão (default) captura qualquer alerta não categorizado, garantindo que nada seja perdido.

4. Integração profunda entre Alertmanager e PagerDuty

A configuração do receiver PagerDuty exige uma routing_key (integration key) e permite enriquecer o payload com contexto:

receivers:
  - name: 'pagerduty-critical'
    pagerduty_configs:
      - routing_key: 'SEU_INTEGRATION_KEY_AQUI'
        severity: 'critical'
        description: '{{ .GroupLabels.alertname }} - {{ .GroupLabels.service }}'
        details:
          summary: 'Alerta crítico detectado'
          source: 'Prometheus'
          custom_details:
            service: '{{ .GroupLabels.service }}'
            region: '{{ .GroupLabels.region }}'
            current_value: '{{ .Annotations.current_value }}'

O mapeamento de severidades pode ser feito diretamente no Alertmanager ou via transformação de labels. Exemplo de mapeamento:

  • severity: critical → Prioridade P1 no PagerDuty
  • severity: warning → Prioridade P2
  • severity: info → Prioridade P3

Para payloads customizados, use os campos text, links e images:

pagerduty_configs:
  - routing_key: 'SEU_KEY'
    links:
      - href: 'https://grafana.example.com/d/{{ .GroupLabels.service }}'
        text: 'Dashboard do serviço'
    images:
      - src: 'https://monitoring.example.com/graph/{{ .GroupLabels.service }}.png'
        alt: 'Gráfico atual'

5. Estratégias de escalonamento e deduplicação no PagerDuty

No PagerDuty, crie escalation policies por nível de criticidade:

  • P1: Notifica engenheiro sênior imediatamente, escalona para gerente após 10 minutos
  • P2: Notifica equipe primária, escalona após 20 minutos
  • P3: Notifica equipe em horário comercial, escalona após 1 hora

A deduplication key no PagerDuty evita múltiplos incidentes para o mesmo problema. Configure no Alertmanager:

pagerduty_configs:
  - routing_key: 'SEU_KEY'
    dedup_key: '{{ .GroupLabels.service }}:{{ .GroupLabels.alertname }}'

Para auto-resolve, use o campo auto_resolve no PagerDuty ou envie um evento de resolução via webhook quando o alerta no Prometheus for resolvido.

6. Monitoramento da qualidade dos alertas com métricas e dashboards

O próprio Alertmanager expõe métricas importantes:

# Total de alertas ativos
alertmanager_alerts{alertstate="active"}

# Total de notificações enviadas por receiver
alertmanager_notifications_total{receiver="pagerduty-critical"}

# Alertas silenciados
alertmanager_alerts{alertstate="suppressed"}

Crie dashboards no Grafana para monitorar:

  • Taxa de alertas por severidade ao longo do tempo
  • Tempo médio de resolução (MTTR)
  • Proporção de falsos positivos (alertas que foram silenciados manualmente)
  • Falhas de entrega (notificações com erro)

Além disso, configure alertas sobre os próprios alertas:

# Alerta se não houver notificações por mais de 1 hora
- alert: NoNotifications
  expr: rate(alertmanager_notifications_total[1h]) == 0
  for: 1h

7. Casos práticos e troubleshooting de alertas inteligentes

Exemplo prático: agrupamento de alertas de latência

Suponha que você tenha múltiplos pods de um microsserviço apresentando alta latência. Com a configuração abaixo, todos os alertas do mesmo serviço e região são agrupados:

group_by: ['service', 'region', 'severity']
group_wait: 1m

Se 10 pods ficam lentos simultaneamente, apenas um incidente é criado no PagerDuty, com os detalhes de todos os pods no payload.

Debug com amtool

Use amtool para testar rotas sem enviar notificações reais:

amtool alert --alertmanager.url=http://localhost:9093 --annotation.summary="Teste" --label.severity="critical"

Para verificar logs do Alertmanager:

journalctl -u alertmanager -f | grep -i "pagerduty"

Evitando alertas fantasmas

Configure thresholds dinâmicos baseados em baselines históricas. Por exemplo, ao invés de um threshold fixo de 80% de CPU, use:

- alert: HighCPUAnomaly
  expr: avg by(service) (cpu_usage_percent) > (avg_over_time(cpu_usage_percent[7d]) * 1.5)

Isso dispara apenas quando o uso atual excede 50% acima da média dos últimos 7 dias, adaptando-se a padrões sazonais.

Referências