Explica as armadilhas de engenharia de alertar sobre métricas de utilização de recursos em vez de latência voltada para o usuário e taxas de erro.
São 3h15. Seu celular vibra com um incidente de alta prioridade no PagerDuty: CRÍTICO: Utilização de CPU do servidor API > 95%. Você abre o laptop, acessa o dashboard do Grafana e percebe que, embora a CPU tenha disparado por 4 minutos, a taxa de erros HTTP 500 permaneceu em 0% e a latência da API ficou completamente estável.
Você confirma o alerta, suspira fundo e volta a dormir. Você acabou de experimentar a definição clássica de um alerta terrível.
Por décadas, o monitoramento de infraestrutura tem dependido fortemente de métricas de utilização como CPU e memória. Mas na era dos microsserviços em contêineres e da infraestrutura de nuvem com autoscaling, alertar sobre consumo de recursos é um antipadrão. Este artigo explora o porquê.
Para entender por que ainda configuramos alertas de limite de CPU, precisamos voltar à era dos servidores físicos. Quando você tinha um único servidor de banco de dados em um rack, uma CPU atingindo 99% significava que a máquina não tinha mais capacidade computacional. Se o tráfego aumentasse minimamente, o servidor inevitavelmente travaria.
A arquitetura de nuvem moderna opera de forma diferente. Implantamos explicitamente grupos de autoscaling para maximizar a utilização de recursos e reduzir os custos de computação em nuvem. Se um nó funciona consistentemente a 40% de CPU, você está superprovisionado. Na verdade, você quer que os nós operem eficientemente perto de seus limites, permitindo que o escalonamento horizontal absorva o excesso.
Quando a camada de orquestração lida com o influxo, CPU alta é sinal de um sistema saudável e econômico — não uma emergência.
Ao projetar um alerta, você deve diferenciar a causa de um problema do sintoma que os usuários experimentam.
Um pico de memória é uma causa (ou estado subjacente). Um usuário recebendo um erro 502 Bad Gateway é um sintoma (a dor real).
Se um cron job em segundo plano consome 100% da CPU de um nó por dois minutos processando um arquivo grande, mas roda em uma fila de workers dedicada, o usuário experimenta exatamente zero degradação de performance. Acionar um engenheiro por isso cria puro ruído.
Por outro lado, um deadlock no banco de dados pode consumir apenas 5% da CPU do banco, mas paralisa todas as transações dos usuários. Se você alerta apenas sobre CPU, vai perder completamente a interrupção crítica.
Vamos examinar três cenários comuns em que picos de utilização de recursos geram falsos positivos:
Em linguagens como Java ou Go, picos de memória intermitentes são esperados à medida que objetos são alocados antes que uma pausa do GC os limpe. Disparar alertas de memória com base nessas ondas em dente de serra é notoriamente instável.
Um backup noturno do banco de dados ou uma rotação de logs naturalmente exige intenso I/O de disco e CPU. A menos que impeça as funções primárias da aplicação, não justifica um alerta.
Um afluxo repentino de conexões sobrecarregará imediatamente a CPU enquanto handshakes TLS são negociados e pools de conexões são aquecidos. Enquanto a aplicação escalar horizontalmente de forma eficaz em alguns minutos, a saturação breve é procedimento operacional padrão.
Alertas de pager devem ser reservados exclusivamente para os "Sinais Dourados": Latência, Tráfego, Erros e Saturação.
Em vez de: CPU > 90%
Alerte sobre: Latência P99 > 1500ms por 5m
Se a CPU atingir 99% mas a latência ficar seguramente abaixo do limite de 1500ms, deixe a equipe dormir.
Em vez de: Memória > 85%
Alerte sobre: Taxa de Erros HTTP 5xx > 2%
Se um vazamento de memória eventualmente causar reinicializações de Pods resultando em requisições perdidas, o alerta de taxa de erros 5xx detectará o sintoma e acionará a equipe com precisão.
Métricas de CPU e memória não são inúteis — elas simplesmente não merecem uma notificação urgente.
Essas métricas pertencem a dois lugares:
Pare de criar escalas de on-call baseadas na saúde da infraestrutura. Construa-as em torno da saúde dos usuários. Ao eliminar os limites brutos de hardware e assumir o compromisso com alertas de latência e erro baseados em sintomas, os engenheiros sofrem menos fadiga e confiam nos alertas que realmente disparam.
A transição requer telemetria externa confiável. Plataformas como o Heimdall monitoram exatamente o que o usuário experimenta — aplicando alertas com base em latências HTTP reais e capacidades reais de resolução DNS — permitindo que as equipes desliguem com segurança as regras de limite de CPU ruidosas dentro de seus clusters.
Junte-se a milhares de equipes que confiam no Heimdall para manter seus sites e APIs online 24/7. Comece com nosso plano gratuito hoje.
Comece a monitorar gratuitamente
Engenheiro de Confiabilidade de Sistemas (SRE) Sênior focado em disponibilidade, resposta a incidentes e construção de sistemas de monitoramento que antecipam problemas antes que os usuários percebam.
