Por que logs não são suficientes?

Welton Batista — Thu, 16 Jan 2025 03:21:00 +0000

Imagine que você é acionado bem cedo com uma ligação informando que o sistema da empresa parou de funcionar. Está chegando o momento em que a operação será iniciada, mais precisamente nos próximos 60 minutos. A pressão bate na porta, e as coisas precisam voltar ao normal o mais rápido possível. Enquanto isso, a equipe te envia um conjunto de logs que já foram coletados pelo pessoal do NOC. Esses logs contêm informações de pelo menos 10 sistemas diferentes. Aposte suas fichas: você acredita que seria capaz de identificar o problema nesse tempo? Pois esse é o problema de confiar apenas em logs!
Antes de avançar, preciso deixar um aviso importante: logs são ferramentas essenciais para depuração e monitoramento de sistemas. Dito isso, apenas logs podem não ser suficientes!

Limitações dos logs tradicionais

Falta de contexto
Quando analisamos um log isoladamente, não temos uma visão geral do que aconteceu antes ou depois. Temos apenas um registro do ocorrido em um instante específico de um único sistema. Isso prejudica muito nossa percepção geral sobre o problema. Surgem questões como:

"Será que esse erro está relacionado com o problema que estou investigando?"

Problemas de volume e escalabilidade
Em cenários de grande escala, onde há uma enorme variedade de sistemas com níveis de detalhamento elevados, como logs configurados em INFO ou DEBUG, a análise manual pode se tornar inviável. Isso também aumenta os custos de armazenamento e processamento, além de tornar a busca por informações relevantes em meio a uma grande quantidade de dados quase uma missão impossível. Ou, como dizem, é como tentar achar uma agulha no palheiro.

Falta de estrutura e padronização
Um ponto crítico é a falta de padronização ao registrar logs não estruturados (apenas texto simples). Isso dificulta buscas e filtros. Essa falta de padronização está diretamente ligada à forma como cada desenvolvedor interpreta e julga o que é relevante registrar. Quanto mais equipes dentro da empresa, mais "silos" de informação são criados, o que acaba gerando distorções e inconsistências.

Problemas de desempenho
O registro excessivo de logs pode impactar negativamente o desempenho da aplicação, especialmente se o armazenamento for síncrono. Embora possamos filtrar o excesso de logs, a contrapartida pode ser a perda de informações cruciais.

Conclusão
Embora os logs sejam fundamentais para sistemas de software, confiar exclusivamente neles não é suficiente para entender e diagnosticar problemas, especialmente em sistemas distribuídos. A falta de contexto, correlação e granularidade impede a resolução rápida de problemas, principalmente em arquiteturas modernas.
Por isso, a combinação de logs com práticas como rastreamento distribuído e métricas é essencial para alcançar uma verdadeira observabilidade.
Na próxima vez, vou escrever sobre como resolver essas limitações com a tríade Logs, Métricas e Traces.

Resiliência em Sistemas: Explorando o Constant Work Pattern (CWP)

Welton Batista — Thu, 25 Jul 2024 01:18:17 +0000

Eu quero falar sobre um conceito chamado de Constant Work Pattern (CWP) para isso vamos imagina um cenário fictício de uma aplicação no contexto de pagamento. Suponha que temos um sistema de pagamento com dois fluxos: o principal, integrado com o parceiro Pagamentos Feliz S/A, e o alternativo, ou fallback, com o parceiro Pague Aqui LTDA. Enquanto o fluxo principal é mais detalhado e amplamente testado, o fluxo alternativo, embora funcional, é menos explorado e possui menor vivência.

O princípio do CWP visa eliminar a diferença entre fluxos principais e alternativos, garantindo que ambos sejam acionados com a mesma frequência. Dessa forma, qualquer falha em um fluxo pode ser compensada pelo outro, aumentando a resiliência do sistema.

Na prática, o CWP assegura uma exploração equilibrada de todos os fluxos, proporcionando um entendimento mais profundo sobre os diferentes cenários e nuances que podem surgir em produção. Isso resulta em uma abordagem mais robusta e resiliente, com impactos reduzidos em caso de problemas. Portanto, a adoção do Constant Work Pattern faz sentido do ponto de vista da resiliência, pois permite uma exploração abrangente dos fluxos principais e alternativos, ajudando a equipe a compreender melhor o sistema e identificar problemas potenciais com impacto minimizado.

Failover Quebra o Princípio do Constant Work Pattern (CWP)?

Para entender se o failover quebra o princípio do CWP, primeiro precisamos definir o que é failover. Trata-se de uma aplicação com duas ou mais instâncias idênticas, localizadas em servidores ou regiões diferentes, prontas para assumir o lugar da instância primária em caso de falha.

Por exemplo, em nossa API de pagamentos, podemos ter o parceiro Pagamentos Feliz S/A acessível em um endereço como https://pagamento.feliz.1/process. Em caso de falha, a API pode alternar para um segundo endereço, como https://pagamento.feliz.2/process. A questão é: esse desenho de solução fere o princípio do CWP?

Na minha visão, não! Isso ocorre porque, mesmo que a API de pagamentos mude de endereço, ela está chamando a mesma aplicação com o mesmo contrato e comportamento semântico. Não há quebra de contrato nem um fluxo alternativo de processamento. Portanto, o failover, que se refere à troca entre instâncias idênticas e funcionais, não viola o princípio do CWP, ao contrário do que ocorre com o fallback.

Confira os seguintes links úteis sobre os temas abordados:

Fallback e CWP na visão de um arquiteto da AWS: https://aws.amazon.com/pt/builders-library/avoiding-fallback-in-distributed-systems/

Failover: https://www.cloudflare.com/pt-br/learning/performance/what-is-server-failover/#:~:text=O%20failover%20de%20servidor%20%C3%A9,como%20um%20gerador%20de%20backup.

DEV Community: Welton Batista

Por que logs não são suficientes?

Limitações dos logs tradicionais

Resiliência em Sistemas: Explorando o Constant Work Pattern (CWP)