Detectar problemas antes dos clientes

Uma estrutura pequena com um ponto cego crescente. No começo, havia poucos servidores e scripts lendo logs. Conforme a plataforma cresceu, a abordagem não acompanhou nem o volume nem a complexidade. E, acima de tudo, era reativa: contava o que já tinha acontecido.

Chefe e cliente não são ferramentas de monitoramento. Por que só perceber um problema depois que ele acontece? Se um gestor ou cliente é o primeiro a avisar da queda, a operação já está atrasada. Além do incidente, isso compromete a confiança na equipe, dentro e fora da organização.

O clássico: um certificado TLS prestes a vencer. Em 2000, a automação de renovação conhecida hoje não existia da mesma forma. O Let’s Encrypt só chegou em 2015. Precisávamos acompanhar a validade antes de descobrir o problema numa conexão quebrada. Requisitos e emissores variam; mesmo a renovação automática precisa ser monitorada.

Detectar, avisar e guardar evidências. As primeiras escolhas foram Nagios e Zabbix. Precisávamos detectar problemas e avisar alguém que pudesse agir, especialmente a equipe de plantão 24/7. Na época, o orçamento ainda não permitia uma arquitetura de alta disponibilidade. Detecção confiável e resposta rápida eram essenciais para a melhor qualidade possível; monitoramento não eliminava o risco de indisponibilidade. Com os anos, os canais incluíram SMS, WhatsApp e PagerDuty. Isso veio depois, não significa que tudo já era usado em 2000.

Dos incidentes às tendências. Registrar métricas permitiu olhar além de um alarme: como carga, latência e capacidade disponível mudavam? Grafana e Checkmk se juntaram depois. O objetivo continuou o mesmo: perceber deterioração cedo e entender para onde o sistema ia.

O princípio que ficou. Monitoramento não é só uma coleção de dashboards. Ele deve dar à equipe a chance de agir antes que alguém precise avisar que há um problema.

Referência histórica: anúncio do primeiro certificado público do Let’s Encrypt, em 2015.