Ultimamente tenho participado de diversas conversas com desenvolvedores que têm dúvidas sobre como monitorar o desempenho de softwares criados por eles. Com base nessas conversas, quero aproveitar este espaço para falar um pouco sobre formas de monitoramento de serviços, e não somente sobre tecnologias em si. Afinal, tecnologia é um pouco como gente: cada uma tem seu lado positivo e negativo e está sempre cercada de pessoas que a amam ou odeiam, sem nem sempre entender o porquê.

Quando falamos de serviços rodando 24×7, é fundamental conhecer muito bem o sistema ou o software para entender qual é o comportamento desejado: utilização de rede, CPU, memória, disco, quantidade de mensagens de alerta em logs, quantidade de erros em logs, número de ativos em um determinado período, entre outros. Também é importante compreender o desempenho do software, obter números de latência e outras informações específicas sobre o serviço que é oferecido.

De forma geral, desenvolvedores e administradores acompanham o funcionamento de seus serviços para saber quando as coisas param de funcionar. Para isso, são criados diversos monitores na tentativa de capturar falhas no sistema. A intenção é, na ocorrência de um incidente, ter conhecimento de que há algo errado ou inesperado. Entretanto, é no momento em que os problemas acontecem (e eles sempre acontecem) que os envolvidos percebem que não estavam monitorando o serviço em um sinal específico, que naquela ocasião foi o sintoma de uma falha.

Pela minha experiência, acredito que o erro mais comum cometido durante o monitoramento de desempenho ocorre na sequência de incidentes que causam alguma interrupção no serviço. Nesse tipo de situação, todo o foco inicial vai para resolver o problema e restabelecer o serviço. Só então os responsáveis preocupam-se com os sintomas que diversas vezes passaram despercebidos. É então, no “calor do momento”, que monitores (código para detecção de certos comportamentos) e alertas (métodos de notificação para esses monitores) são criados para todos os sintomas de que algo está errado. E isso se repete cada vez que um incidente ocorre.

Existe uma percepção de que esse tipo de resposta a incidentes garante que da próxima vez o sistema estará mais preparado. Mas isso nem sempre é verdade.

O que acontece é que os sistemas, a cada vez, “encontram” um jeito novo e impressionante de falhar, e as coisas falham de uma forma sempre mais fantástica. Querer prever todos os tipos possíveis de falhas é como mirar em um alvo móvel, ou como dizemos em inglês “aiming at a moving target”. Pode ser divertido e poupar tempo, mas é extremamente ineficiente.

Então, como se preparar para incidentes e saber o que realmente está acontecendo?

Minha resposta para essa pergunta é: identifique e aposte no bom comportamento. Se você sabe qual é e tem dados de diversos ângulos sobre o comportamento esperado, sempre que algo estiver fora da normalidade você será alertado. Esse conhecimento vai fazer com que você sempre saiba das falhas, não importa qual a situação que levou o sistema a isso, pois elas são um desvio do bom comportamento do serviço. Comportamento esse que, vale lembrar, não muda tão frequentemente.

Assim, fica claro que sistemas de monitoramento de desempenho são somente um alerta de que algo está errado e não podem ser confundidos com sistemas de diagnóstico de falhas. Para encontrar a solução ou a causa central de um problema, é necessário investir em ferramentas de diagnóstico. Por fim, separar a expectativa entre diagnóstico e monitoramento é essencial para que façamos um bom trabalho em cada uma dessas disciplinas, que são igualmente importantes, mas completamente diferentes entre si.

***

Artigo publicado originalmente da Revista iMasters de maio.