A equipa SRE média recebe mais de 500 alertas por semana. Destes, menos de 5% exigem intervenção humana. O resto é ruído — picos transitórios, avisos informativos e notificações duplicadas que ensinam os engenheiros a ignorar os alertas por completo.
Isto não é um problema de tecnologia. O Prometheus, o Grafana e os stacks de monitorização modernos conseguem detetar qualquer coisa. O problema é que a maioria das equipas cria alertas para tudo em vez de criar alertas para o que importa.
Um bom sistema de alertas em Kubernetes assenta em três princípios: alertar apenas para sintomas que afetam os utilizadores, encaminhar as notificações para o canal certo com a urgência certa e refinar continuamente o sistema com base no que exigiu realmente uma ação.
Eis como implementar estes princípios em toda a tua infraestrutura Kubernetes.
O problema da fadiga de alertas
A fadiga de alertas é o maior risco para a fiabilidade operacional. Quando os engenheiros recebem centenas de alertas por dia, desenvolvem mecanismos de defesa: silenciar canais, ignorar notificações e assumir que os alertas são falsos positivos. Quando acontece um incidente real, recebe o mesmo tratamento — é ignorado até um cliente reportar o problema.
A causa raiz é normalmente um de três padrões.
Alertar para causas em vez de sintomas. Um alerta de "utilização de CPU acima de 80%" dispara constantemente mas raramente indica um problema real. O Kubernetes lida bem com uma utilização elevada de CPU — o que importa é se a latência ou a taxa de erros aumentaram por causa disso.
Nenhuma diferenciação por severidade. Indisponibilidades críticas e avisos informativos chegam pelo mesmo canal e com a mesma urgência. Quando tudo é urgente, nada é urgente.
Falta de deduplicação. Um único pod a falhar gera alertas a partir do próprio pod, do controlador do deployment, do nó e do stack de monitorização — quatro notificações para um só problema.
Construir uma estratégia de alertas que funcione
Passo 1: define o que merece um alerta
Nem todas as anomalias numa métrica precisam de uma resposta humana. Estrutura os teus alertas em três níveis.
Nível 1 — Chamar o piquete (acordar alguém): Impacto nos utilizadores neste momento. Taxa de erros acima do limiar do SLO. Indisponibilidade total do serviço. Risco de perda de dados. Indícios de uma violação de segurança. Vão para o PagerDuty ou o OpsGenie e chamam o engenheiro de piquete.
Nível 2 — Notificar (próximo dia útil): Impacto potencial se não for tratado em breve. Utilização de disco acima de 85%. Certificado a expirar em 7 dias. Número de reinícios de pods a aumentar. Deployment preso no rollout. Vão para um canal de Slack ou para email — urgentes, mas não imediatos.
Nível 3 — Registar (para investigação): Sinais informativos úteis para depuração. Picos temporários de CPU. Reinícios isolados de pods. Aumentos breves da latência de rede. Vão para dashboards e logs, não para pessoas.
A maioria das equipas começa com tudo no Nível 1. A disciplina está em ir descendo as coisas de nível.
Passo 2: alerta para sintomas, não para causas
A regra de ouro dos alertas SRE: alerta para aquilo que os utilizadores sentem, não para aquilo que achas que pode causar problemas.
Em vez de: "CPU do nó acima de 90%" Alerta para: "Latência P99 dos pedidos acima de 500ms durante 5 minutos"
Em vez de: "Utilização de memória do pod acima de 80%" Alerta para: "Eventos OOMKill detetados no namespace de produção"
Em vez de: "Utilização de disco acima de 75%" Alerta para: "Esgotamento previsto do disco dentro de 4 horas ao ritmo de escrita atual"
Os alertas baseados em sintomas reduzem o ruído em 80% porque só disparam quando os utilizadores são realmente afetados. Um nó a 95% de CPU está bem se a latência estiver normal. Um nó a 40% de CPU com picos de latência é um problema real.
Passo 3: implementa um encaminhamento inteligente
Alertas diferentes precisam de canais diferentes. Uma indisponibilidade crítica não deve chegar ao mesmo canal de Slack que um lembrete de renovação de certificado.
Configura regras de encaminhamento com base na severidade e em quem é responsável por cada serviço:
Canais de Slack: Cria canais dedicados por equipa ou por área de serviço. Encaminha os alertas de Nível 2 para o canal da equipa responsável. Inclui contexto suficiente na mensagem para o engenheiro decidir se age agora ou mais tarde.
Notificações por email: Usa-as para alertas de Nível 2 que não precisam de visibilidade imediata mas devem ser acompanhados. Emails de resumo semanal com as tendências do Nível 3 ajudam as equipas a identificar problemas que se vão agravando lentamente.
Webhooks: Integra com sistemas de tickets (Jira, Linear) para criar tickets automaticamente para os alertas de Nível 2. Assim nada se perde pelo caminho, sem acrescentar pressão de notificações.
PagerDuty/OpsGenie: Reservados exclusivamente para o Nível 1. Se um alerta não justifica acordar alguém às 3 da manhã, não pertence ao sistema de piquete.
Plataformas como o SRExpert oferecem encaminhamento de alertas multicanal com throttling inteligente incluído. Defines regras de alerta a partir de métricas do Prometheus e de eventos do Kubernetes, estabeleces níveis de severidade e encaminhas para Slack, Email, PagerDuty ou webhooks personalizados. A plataforma trata da deduplicação e do acompanhamento da entrega, por isso sabes que cada alerta foi entregue e confirmado — acabou-se o "não vi o alerta" nos postmortems.
Passo 4: acrescenta throttling inteligente e deduplicação
Um único incidente pode desencadear dezenas de alertas relacionados. Sem deduplicação, o engenheiro de piquete recebe 50 notificações para um só problema e perde tempo a fazer triagem em vez de resolver.
Agrupamento de alertas: Agrupa os alertas por namespace, serviço ou domínio de falha. Se 10 pods do mesmo deployment estiverem a falhar, envia um alerta com a contagem — não 10 alertas individuais.
Limita os alertas repetidos: Se o mesmo alerta disparar continuamente, envia a notificação inicial, um lembrete aos 15 minutos se não tiver sido confirmado, e depois suprime-o até a condição mudar. Não envies o mesmo alerta a cada 60 segundos durante horas.
Correlação: Quando vários alertas de serviços relacionados disparam numa janela de 2 minutos, correlaciona-os num único incidente. Um alerta de base de dados mais um alerta de API mais um alerta de frontend são um incidente, não três.
Inibição: Se disparar um alerta ao nível do nó, suprime os alertas ao nível dos pods nesse nó. O problema do nó é a causa raiz — os alertas dos pods individuais são apenas sintomas.
Passo 5: monitoriza o teu sistema de alertas
O próprio sistema de alertas precisa de monitorização. Os health checks dos canais garantem que os webhooks de Slack, os relays de email e as integrações com o PagerDuty estão mesmo a funcionar. Um alerta perfeitamente configurado que não consegue chegar ao engenheiro de piquete é pior do que não ter alerta nenhum.
Acompanha estas meta-métricas do teu sistema de alertas:
Taxa de entrega de alertas: Que percentagem dos alertas é entregue com sucesso no canal configurado? Falhas de webhooks, emails devolvidos e rate limits de APIs podem fazer desaparecer alertas silenciosamente.
Tempo de confirmação: Quanto tempo passa entre a entrega do alerta e a confirmação por uma pessoa? Se os alertas de Nível 1 demoram em média 30 minutos a ser confirmados, o teu encaminhamento ou a tua política de escalamento precisam de ajustes.
Taxa de falsos positivos: Que percentagem dos alertas de Nível 1 não exige nenhuma ação? Se mais de 20% forem falsos positivos, os limiares dos teus alertas precisam de afinação.
Rácio alertas/incidente: Quantos alertas são precisos para identificar um incidente real? Um rácio acima de 10:1 indica ruído excessivo.
O SRExpert inclui health checks de canais e acompanhamento da entrega para cada canal de notificação configurado. Se um webhook de Slack começar a falhar ou um relay de email for abaixo, és notificado sobre a falha da notificação — garantindo que o teu sistema de alertas nunca se degrada em silêncio.
Regras de alerta práticas para Kubernetes
Eis regras de alerta testadas em produção que equilibram a qualidade do sinal com a cobertura.
Saúde das cargas de trabalho
Taxa de erros elevada: Alerta quando a taxa de erros 5xx ultrapassar 1% do total de pedidos durante 5 minutos. Apanha a degradação real do serviço e ignora os erros transitórios.
Pod em CrashLoopBackOff: Alerta quando um pod tiver reiniciado mais de 5 vezes em 15 minutos. CrashLoopBackOff é quase sempre um problema real — configuração errada, dependências em falta ou esgotamento de recursos.
Rollout de deployment preso: Alerta quando um deployment não tiver concluído o rollout em 10 minutos. Rollouts presos indicam falhas no pull de imagens, falhas de health check ou contenção de recursos.
HPA no máximo: Alerta quando o Horizontal Pod Autoscaler estiver no número máximo de réplicas há 30 minutos. Significa que o serviço não consegue aguentar a carga atual com os limites de scaling configurados.
Saúde da infraestrutura
Nó não pronto: Alerta de imediato quando um nó passar a NotReady. Isto afeta todos os pods agendados nesse nó.
Volume persistente perto da capacidade: Alerta quando a utilização do PV ultrapassar 85%. Ao contrário do armazenamento efémero, os volumes persistentes não podem ser expandidos automaticamente na maioria das configurações.
Latência do etcd: Alerta quando a duração de commit do etcd ultrapassar 100ms. Uma latência elevada do etcd afeta todo o plano de controlo.
Eventos de segurança
Contentor privilegiado detetado: Alerta quando um novo pod correr com um security context privilegiado num namespace de produção. Isto nunca deve acontecer num cluster devidamente protegido.
Criação inesperada de namespaces: Alerta para a criação de novos namespaces fora do teu pipeline GitOps. A criação manual de namespaces indica muitas vezes acesso não autorizado ou operações na sombra.
Melhoria contínua: o processo de revisão de alertas
Os alertas nunca estão "concluídos". Marca uma revisão mensal de alertas com a tua equipa SRE.
Revê todos os alertas de Nível 1 do último mês. Para cada um, pergunta: exigiu ação humana? Se não, passa-o para o Nível 2 ou afina o limiar. O alerta era acionável — o engenheiro sabia o que fazer? Se não, acrescenta um link para um runbook. O alerta chegou a tempo — disparou antes de os utilizadores reportarem o problema? Se não, aperta a janela de deteção.
Revê os alertas de Nível 2 que foram ignorados. Se um alerta de Nível 2 é sistematicamente ignorado durante semanas, ou não é importante (remove-o) ou o encaminhamento está errado (passa-o para um canal mais visível).
Revê os incidentes que não tiveram alertas. São as lacunas mais perigosas. Se aconteceu um incidente sem o alerta correspondente, tens um ponto cego de deteção que precisa de uma nova regra de alerta.
Este ciclo mensal reduz continuamente o ruído, fecha lacunas de deteção e garante que o teu sistema de alertas evolui com a tua infraestrutura.
Conclusão
Um bom sistema de alertas em Kubernetes não tem a ver com detetar mais — tem a ver com detetar melhor. Cada alerta do teu sistema deve acordar alguém, desencadear uma ação no dia útil seguinte ou alimentar um dashboard. Se não encaixa numa destas categorias, não deve existir.
Constrói os teus alertas em torno de sintomas que afetam os utilizadores, não de métricas de infraestrutura. Encaminha os alertas para o canal certo com a severidade certa. Deduplica e aplica throttling para evitar a fadiga. Monitoriza a tua monitorização para garantir fiabilidade. E revê continuamente para manter o sistema afinado.
O objetivo é um sistema de alertas em que cada notificação é esperada, compreendida e acionável. Quando o teu engenheiro de piquete vê um alerta, o primeiro pensamento deve ser "sei o que tenho de fazer" — e não "lá vamos nós outra vez".
Deixa de te afogar em ruído de alertas. O SRExpert oferece encaminhamento inteligente de alertas com deduplicação inteligente, entrega multicanal (Slack, Email, PagerDuty, Webhooks) e monitorização da saúde dos canais. Começa a explorar agora ou fala com a nossa equipa SRE para otimizar a tua estratégia de alertas.