Alertmanager: como funciona o gerenciamento de alertas no ecossistema Prometheus
Configurar boas regras de alerta no Prometheus é só metade do trabalho. A outra metade é garantir que cada disparo chegue à pessoa certa, no canal certo, sem inundar o time com avisos repetidos. Sem essa camada, o monitoramento vira ruído: alertas críticos se perdem no meio de dezenas de notificações irrelevantes.
Uma pesquisa da Grafana Labs com 1.363 profissionais aponta: para 30% deles, a fadiga de alertas é o maior obstáculo à resposta rápida a incidentes.
É exatamente essa lacuna que o Alertmanager preenche. Neste artigo, você vai entender como ele funciona no ecossistema Prometheus e como configurar rotas e receivers na prática. Além disso, verá quando complementá-lo com ferramentas de plantão em equipes de SRE e operações 24×7.
O que é o Alertmanager
O Alertmanager é o componente do ecossistema Prometheus responsável por gerenciar alertas. Ele recebe os disparos das regras de alerta e aplica deduplicação, agrupamento, silêncios e inibição. Em seguida, roteia cada notificação para canais como e-mail, Slack, PagerDuty e webhooks. Na prática, ele decide quem recebe qual alerta, quando e por qual meio.
O projeto nasceu dentro do ecossistema Prometheus e é mantido pela mesma comunidade open source. Ele roda como um binário independente, expõe uma interface web na porta 9093 e não exige banco de dados externo.
Vale destacar que a adoção do ecossistema segue alta. Na Observability Survey 2024, 89% dos respondentes afirmaram investir em Prometheus, o que torna o Alertmanager peça padrão na maioria das stacks modernas.
Como o Alertmanager funciona no ecossistema Prometheus
No ecossistema Prometheus, o Alertmanager atua como a camada de notificação. O servidor de monitoramento com Prometheus avalia as regras e envia os disparos via HTTP ao Alertmanager. Dali em diante, ele assume o ciclo completo: deduplicar, agrupar, silenciar e rotear cada notificação.
Essa separação de responsabilidades é proposital. O Prometheus decide quando um alerta existe; o Alertmanager decide o que fazer com ele. Dessa forma, várias instâncias de Prometheus podem apontar para o mesmo Alertmanager, que centraliza a política de notificação de toda a operação.
Notificar direto do servidor de métricas parece mais simples, porém não escala. Sem a camada intermediária, cada instância enviaria seus próprios e-mails, com duplicatas a cada avaliação de regra e nenhum controle central de silêncios.
Cada alerta passa por três estados. Ele nasce como Pending enquanto a condição ainda não completou a duração mínima definida na regra. Em seguida, muda para Firing quando o problema se confirma. Por fim, o Alertmanager envia um aviso de Resolved assim que a condição volta ao normal, se o receiver estiver configurado para isso.
Agrupamento, deduplicação, silêncios e inibição
Quatro mecanismos formam o coração do Alertmanager. Juntos, eles transformam uma enxurrada de disparos brutos em poucas notificações acionáveis, aplicando a lógica de deduplicação e agrupamento de alertas antes de qualquer envio.
| Mecanismo | O que faz | Quando usar |
|---|---|---|
| Agrupamento | Junta alertas com os mesmos labels (via group_by) em uma única notificação |
Incidentes que derrubam vários alvos ao mesmo tempo, como a queda de um cluster inteiro |
| Deduplicação | Descarta cópias do mesmo alerta enviadas por instâncias redundantes do Prometheus | Arquiteturas com dois servidores avaliando as mesmas regras em paralelo |
| Silêncio | Suprime notificações que casam com labels definidos, por tempo determinado | Janelas de manutenção programada e mudanças planejadas |
| Inibição | Bloqueia alertas dependentes enquanto um alerta de nível superior está ativo | Evitar avisos de serviços que dependem de um recurso que já caiu |
Na prática, os mecanismos trabalham em sequência. Primeiro a deduplicação descarta as cópias; depois o agrupamento consolida o que restou. Em seguida, silêncios e inibições filtram o que não deve gerar notificação naquele momento.
Como configurar o Alertmanager na prática
A configuração do Alertmanager fica em um único arquivo YAML, o alertmanager.yml, com três seções. A parte global define padrões, route monta a árvore de roteamento e receivers lista os canais de notificação. Depois de editar, basta recarregar o serviço para aplicar.
Três parâmetros da rota controlam o ritmo das notificações. O group_wait segura a primeira notificação por alguns segundos para juntar alertas que chegam quase juntos. Já o group_interval espaça os avisos sobre novos alertas do mesmo grupo, enquanto o repeat_interval define quando um alerta ainda ativo gera um novo lembrete.
Para cenários avançados, a documentação oficial de configuração detalha matchers com expressões regulares, rotas aninhadas e janelas de horário com time_intervals.
Conectando o Prometheus ao Alertmanager
Do lado do Prometheus, a integração exige duas configurações no prometheus.yml. O bloco alerting aponta para o endereço do serviço, enquanto rule_files carrega os arquivos de regras. Cada regra usa uma expressão em PromQL para definir a condição de disparo.
Canais de notificação: do e-mail ao webhook
Cada receiver aceita um ou mais canais de notificação. Os mais usados incluem email_configs, slack_configs, webhook_configs e integrações nativas com PagerDuty, OpsGenie e Telegram. Um mesmo receiver pode combinar canais, por exemplo Slack para o time e e-mail para o registro formal.
Além disso, o formato das mensagens é personalizável com templates Go. Com eles, a notificação pode incluir o valor da métrica, links para dashboards e instruções de runbook, o que reduz o tempo de diagnóstico no plantão.
Ative também o send_resolved nos canais principais. Avisar que o problema acabou evita investigações desnecessárias e mantém a confiança do time nas notificações.
Alta disponibilidade: o cluster do Alertmanager
O Alertmanager suporta operação em cluster para eliminar o ponto único de falha na cadeia de notificação. As instâncias se comunicam por um protocolo gossip, trocam informações sobre silêncios e notificações já enviadas e deduplicam os avisos entre si.
A configuração usa flags de linha de comando, sem dependências externas:
Importante: o Prometheus deve apontar para todas as instâncias do cluster, não para um load balancer. Assim, cada alerta chega a todos os nós e o próprio gossip garante que apenas uma notificação sai para o destino final.
Limitações do Alertmanager e quando complementar
O Alertmanager resolve muito bem o roteamento, o agrupamento e a deduplicação. Por outro lado, ele não oferece escalas de plantão nativas, políticas de escalonamento automático nem fallback por voz ou SMS quando ninguém responde ao primeiro aviso.
Na prática, isso significa que a escalação de alertas precisa de uma camada adicional. Equipes maduras costumam integrar o Alertmanager a plataformas de on-call ou delegar a triagem a uma operação de NOC 24×7. Nesses arranjos, a ferramenta segue como a camada que higieniza o fluxo antes do acionamento humano.
Outra lacuna é a gestão do ciclo de vida do incidente. O Alertmanager notifica, mas não registra linha do tempo, não coordena war room nem gera post-mortem: essas etapas pedem processos e ferramentas próprias de gestão de incidentes.
Boas práticas para reduzir o ruído de alertas
Um Alertmanager bem configurado é uma das defesas mais eficazes contra a fadiga de alertas. Algumas práticas fazem diferença imediata no volume de notificações que chegam ao time.
Padronize o label severity. Rotas por criticidade só funcionam com rótulos consistentes em todas as regras: alertas critical acordam o plantão, enquanto avisos warning podem esperar o horário comercial.
Use a inibição para dependências. Se o roteador caiu, os alertas dos serviços atrás dele não precisam disparar. Da mesma forma, revise o repeat_interval: lembretes a cada 5 minutos treinam o time a ignorar notificações.
Audite os silêncios com frequência. Um silêncio esquecido esconde alertas críticos sem ninguém perceber. Vale manter a justificativa e o prazo sempre preenchidos ao criar cada um.
Por fim, meça o resultado. Acompanhe o volume de notificações por semana e a taxa de alertas acionáveis: se a maioria não gera ação, o problema está nas regras ou no roteamento, não nas pessoas.
Acorde o plantonista certo, na hora certa, com o contexto certo.
O KeepGreen valida cada evento antes do acionamento: triagem com IA, causa raiz identificada e notificação pelo canal que sua equipe realmente responde, 24 horas por dia.
Conclusão
O Alertmanager é a peça que transforma disparos brutos do Prometheus em notificações úteis. Ele deduplica, agrupa, silencia e roteia alertas com uma configuração declarativa, fácil de versionar. Com poucos parâmetros, como group_wait e repeat_interval, a operação ganha controle fino sobre o ritmo dos avisos.
Entretanto, a ferramenta não cobre todo o ciclo de resposta a incidentes. Escalas de plantão, escalonamento automático e investigação de causa raiz continuam exigindo processos e plataformas complementares.
O caminho maduro combina os dois mundos: Alertmanager como camada de higienização e uma operação estruturada para acionar as pessoas certas. O esforço se paga rápido, porque menos ruído significa plantões mais saudáveis e resposta mais ágil.
Se a sua equipe sofre com excesso de alertas ou precisa estruturar o monitoramento com Prometheus de ponta a ponta, converse com um especialista da OpServices e descubra como reduzir o ruído sem perder nenhum incidente crítico.
Perguntas Frequentes
Qual a diferença entre Prometheus e Alertmanager?
O Alertmanager substitui uma ferramenta de on-call?
Para que servem group_wait, group_interval e repeat_interval?
group_wait segura a primeira notificação por alguns segundos para juntar alertas que chegam quase juntos. O group_interval define o intervalo mínimo antes de avisar sobre novos alertas no mesmo grupo. Já o repeat_interval determina de quanto em quanto tempo um alerta ainda ativo volta a gerar notificação.Como silenciar alertas no Alertmanager?
9093) ou pela CLI amtool. Basta definir os matchers de labels que identificam os alertas, o período de vigência e uma justificativa. Durante uma manutenção programada, por exemplo, um silêncio evita notificações desnecessárias sem alterar as regras de alerta no Prometheus.
