TECTIUS Há um tipo particular de problema que quase toda a gente já viveu. Leva o carro à oficina porque algo está mal. Talvez o motor faça um ruído estranho. Talvez a luz de aviso tenha acendido. Talvez o carro se tenha comportado de forma diferente nos últimos dias.
O mecânico pergunta:
“Pode mostrar-me o que está a fazer?”
Liga o motor.
Nada.
Dá uma volta ao quarteirão.
Continua a não acontecer nada.
O carro está agora a comportar-se na perfeição. Sabe que algo aconteceu. O mecânico não tem razão para duvidar de si. Mas há um problema: a evidência desapareceu.
Os carros modernos tornaram-se muito melhores a guardar essa evidência. Os seus sistemas eletrónicos conseguem registar avarias, condições de funcionamento e outros eventos que mais tarde ajudam a diagnosticar um problema. Mas mesmo assim há limites. O sistema só consegue registar a informação que foi concebido para reter. E é aqui que a analogia com os sistemas de TI se torna interessante.
O problema de investigar o passado
Quando uma aplicação está lenta, uma query à base de dados passa de repente a demorar mais, ou um servidor tem um pico inesperado de recursos, a primeira reação é normalmente olhar para o que está a acontecer agora. Faz sentido. O CPU está alto? Há erros? A base de dados está a responder devagar? Há pedidos a falhar?
Mas muitos dos problemas mais difíceis não são permanentes. Acontecem de forma intermitente. Acontecem em condições específicas. Aconteceram há três dias. Ou aconteceram durante dez minutos no mês passado e não voltaram a acontecer. Quando alguém começa a investigar, pode já estar tudo de volta ao normal.
E depois surge a pergunta inevitável:
“Sabemos como é que o sistema estava quando isto aconteceu?”
Por vezes a resposta é não. Não porque o sistema tenha deixado de funcionar. Porque não guardámos a evidência.
Os dados de hoje podem responder às perguntas de amanhã
Este é um dos aspetos menos óbvios da monitorização e da observabilidade. Muitas vezes recolhemos dados porque temos uma pergunta a que queremos responder hoje. O serviço está disponível? O tempo de resposta está dentro do intervalo esperado? Há erros? A infraestrutura está a ficar sem capacidade? São perguntas importantes.
Mas os dados históricos permitem-nos fazer uma classe diferente de perguntas. A performance está a piorar? Um tempo de resposta de 800 ms pode ser perfeitamente aceitável. A menos que há seis meses fosse de 200 ms. O consumo de recursos está a aumentar? Uma base de dados a usar 70% do armazenamento disponível pode não ser um problema. A menos que há seis meses usasse 40% e a taxa de crescimento não tenha mudado.
Quando é que a degradação começou, de facto? Foi depois de um deployment? De uma alteração de configuração? De uma mudança no volume de transações? De uma mudança no comportamento dos utilizadores? Ou começou gradualmente, muito antes de alguém reparar? Sem informação histórica, estas perguntas tornam-se muito mais difíceis de responder. Por vezes, impossíveis.
Uma única medição diz-nos muito pouco
Considere um exemplo simples. Suponha que medimos o tempo de resposta da aplicação e descobrimos que um pedido demora atualmente 1,2 segundos. Isso é bom ou mau? Não sabemos. Precisamos de contexto.
Talvez normalmente demore 1,5 segundos. Nesse caso, o sistema até melhorou. Talvez normalmente demore 200 milissegundos. Então algo está claramente errado. O valor, por si só, não chega. É o histórico que dá significado ao valor. É por isso que as tendências são muitas vezes mais úteis do que medições isoladas.
Tempo de resposta
1.2s | ●
1.0s | ●
0.8s | ●
0.6s | ●
0.4s | ●
0.2s | ●
+----------------------------> timeAs medições individuais podem parecer todas razoáveis. A tendência, não. E essa distinção importa na operação. Um sistema que está lentamente a piorar pode manter-se dentro dos limiares aceitáveis de hoje durante um tempo surpreendentemente longo. Quando alguém recebe um alerta, o problema de fundo pode já estar a desenvolver-se há meses.
A monitorização não é só alertas
Há uma tendência para pensar na monitorização como um mecanismo para nos dizer quando algo está mal. Esse é, sem dúvida, um dos seus propósitos. Mas os dados de monitorização também podem tornar-se evidência histórica. Podem ajudar-nos a estabelecer linhas de base, a identificar tendências e a perceber mudanças no comportamento do sistema.
Isto é particularmente importante para a performance. A performance raramente é um estado binário de “a funcionar” ou “a não funcionar”. Um sistema pode estar:
- 5% mais lento do que no mês passado;
- a consumir progressivamente mais memória;
- a gerar cada vez mais tráfego de base de dados;
- a processar menos transações por unidade de CPU;
- a demorar mais a concluir tarefas em segundo plano;
- a ter mais retries sem gerar erros visíveis.
Nada disto produz necessariamente um incidente imediato. Mas, em conjunto, pode dizer-nos que algo está a mudar. E, por vezes, a informação mais valiosa não é o valor em si. É a direção em que o valor se está a mover.
Mas devemos guardar tudo?
Não.
Essa seria a resposta fácil, e normalmente a errada. Recolher dados tem um custo. Há armazenamento. Há processamento. Há tráfego de rede. Há complexidade operacional. Há também o problema do ruído.
Um sistema que produz milhões de eventos por hora não se torna necessariamente mais observável só porque guardámos todos. Por vezes, criámos apenas uma pilha muito grande de dados.
A pergunta útil não é, portanto:
“Quantos dados conseguimos recolher?”
É:
“Que evidência é provável que precisemos quando algo correr mal?”
Isso exige critério de engenharia. Temos de considerar o que deve ser medido, com que nível de detalhe, e durante quanto tempo. Alguma informação pode só ser útil durante algumas horas. Outra torna-se muito mais valiosa quando é retida durante meses ou anos. Um evento de diagnóstico detalhado pode não precisar de retenção de longo prazo. Uma linha de base diária de performance pode precisar. Uma alteração de configuração que demora dois minutos a executar pode ser quase irrelevante no momento — até alguém estar a investigar um problema seis meses depois. O contexto importa.
A informação de que não precisamos hoje pode ser a mais útil amanhã
Isto cria um desafio interessante. Quando desenhamos um sistema, sabemos algumas das perguntas a que vamos ter de responder. Não sabemos todas. E isso é particularmente importante nas operações. A pergunta que importa durante um incidente muitas vezes não é a pergunta que esperávamos fazer quando o sistema foi desenhado.
Por exemplo:
“Porque é que esta transação demorou 12 segundos?”
pode acabar por tornar-se:
“Isto só aconteceu a um tipo de transação?”
ou:
“Isto começou depois da migração da base de dados?”
ou:
“A aplicação estava mesmo lenta, ou estava à espera de outro serviço?”
ou:
“O sistema já estava a degradar-se antes de os clientes começarem a reportar problemas?”
Cada pergunta exige evidência diferente. Não conseguimos prever todas as perguntas futuras. Mas podemos desenhar sistemas de forma a preservarem contexto suficiente para as investigar. Essa é uma das razões pelas quais a observabilidade é mais do que pôr um dashboard à frente de um sistema.
A tecnologia vem depois
Há outro ponto importante. Esta discussão não é realmente sobre uma plataforma de monitorização, uma base de dados, uma framework de logging ou um produto de observabilidade em particular. Essas são escolhas de implementação. O ponto de partida deve ser o problema.
Primeiro precisamos de perceber: O que precisamos de saber? Depois: Que evidência precisamos de reter para o saber? Depois: De quanto detalhe e de quanto histórico precisamos, de facto? Só depois disso devemos decidir que tecnologias são adequadas.
A tecnologia deve servir o requisito. Não o contrário. Uma plataforma de monitorização tecnicamente sofisticada não torna automaticamente um sistema observável. Tal como recolher terabytes de logs não torna automaticamente um incidente mais fácil de investigar. O objetivo não é recolher mais dados. O objetivo é ter a evidência certa quando precisamos dela.
De volta à oficina
Isto traz-nos de volta ao carro. A parte difícil de diagnosticar um problema intermitente não é necessariamente encontrar o problema. Por vezes é provar que o problema aconteceu. O mesmo se passa em TI.
Um sistema pode estar perfeitamente saudável quando o investigamos. A base de dados pode estar a responder normalmente. O CPU pode estar calmo. A aplicação pode estar a processar pedidos dentro dos limites esperados. O incidente acabou. Isso não significa que nada tenha acontecido. Pode simplesmente significar que chegámos tarde demais. E se não preservámos a informação certa, podemos nunca saber exatamente o que aconteceu.
A melhor altura para decidir que evidência vamos precisar para investigar um problema é antes de o problema acontecer. Porque, quando o carro chega finalmente à oficina, pode decidir que hoje é um muito bom dia para se portar bem.
O objetivo não é recolher tudo. É preservar evidência suficiente para perceber o que aconteceu.