Monitoração: O terror da falta de rastreabilidade em sistemas distribuídos
Tags: monitoring, devops, distributedsystems, eventdriven
Published: 2022-05-02 22:37:43


[1. Apresentação](#apresentação)
[2. Contexto](#contexto)
[3. Arquitetura Exemplo](#arquitetura-exemplo)
[4. O problema](#o-problema)
[5. A solução é rastrear](#a-solução-é-rastrear)
[6. Algumas ferramentas muito úteis](#algumas-ferramentas-muito-úteis)
[7. Conclusão](#conclusão)

### Apresentação
Quando se fala em arquiteturas e aplicações modernas, a primeira opção em mente são os microsserviços. A estratégia de dividir os contextos de um monólito em demais aplicações também traz problemas "modernos". A monitoração (e mais especificamente a rastreabilidade) é o problema que vamos tratar nesse artigo, esclarecendo a sua importância e seus desafios.

### Contexto
Sistemas distribuídos são compostos por outros microsserviços que trabalham em contextos específicos consumindo e produzindo mensagens que alterar o estado de um objeto principal. Essas mensagens são eventos que são enviados para um barramento de eventos de forma assíncrona produzindo uma arquitetura de mensageria. Muito complexo? De forma resumida, em uma arquitetura baseada em eventos, as aplicações geram mensagens que serão enviadas para um centralizador, e essas mensagens serão consumidas por outras aplicações de forma desacoplada.
No entanto, esse desacoplamento tem um custo que é o rastreamento dos objetos fonte dos eventos. Quanto maior o número de eventos e operações maior a complexidade em monitorar o resultado das operações.

### Arquitetura Exemplo
Vamos imaginar um ecommerce com uma arquitetura distribuída, onde cada estado da experiência do cliente seja um microsserviço. O nosso fluxo será composto de: consultar estoque do produto, gerenciamento de produtos no carrinho, cadastro do cliente, serviço de cotação de frete, verificação de segurança dos dados, verificação de pagamento e processo logístico. Cada etapa desse fluxo será um microsserviço gerando evento por operação executada no objeto pedido - que é o objeto criado pela nossa aplicação principal.

### O problema
A nossa aplicação principal produz um evento que será consumido pelos demais serviços. O nosso objeto pedido possui um campo de estado, indicando a sua posição no fluxo. Os microsserviços não alteram o estado do objeto, mas retornam um evento de resposta em que o único interessado é a nossa aplicação principal. Quando o nosso evento pedido é enviado para o barramento (*centralizador*) a nossa aplicação principal perde o controle do estado da operação. Nesse ponto, o que acontece caso um serviço ocorra em falha durante a sua funcionalidade? E se outros fluxos também quebrarem enquanto processam outros eventos, de que maneira poderemos identificar cada evento e a sua fonte de falha?

### A solução é rastrear
Em um cenário indesejado e catastrófico, nossos eventos se perdem e não teremos resposta do estado da operação. Isso seria terrível!
No mundo ideal cada evento seria uma mensagem composta por id associativo, estado da operação, fonte do evento e a data e hora. Sendo essa mensagem enviada para um log central. Em caso de falha em algum ponto do processo, poderíamos ter uma resposta de erro associado ao id do evento de pedido e tudo suportado por logs, dashboards e métricas.

### Algumas ferramentas muito úteis
* **Splunk**: é uma ferramenta para centralizar logs de forma bem estruturada, e com um serviço de pesquisa orientado ao código. Também fornece gráficos para comparar métricas e macros para segmentar eventos, com tipos definidos pelo programador.
* **Cloudwatch**: muito semelhante ao Splunk mas totalmente vinculado à plataforma da AWS, fornecendo facilidade para aplicações que utilizam o ambiente da cloud AWS.
* **Graphana**: é uma ferramenta que fornece gráficos e tabelas para análise de métricas, além da possibilidade de configurar dashboards personalizados e alarmes.
* **Jaeger**: ferramenta para fazer tracing (*rastreamento*) de todo o fluxo de uma requisição. O Jaeger consegue fazer análise de dependência, causa raiz de falhas, problemas com latência e otimização e monitoramento da propagação do evento.

### Conclusão
Uma arquitetura de sistemas distribuídos que opera direcionado a eventos (*eventdriven*), possui um fluxo muito intenso de troca de mensagens e depende da resposta entre os microsserviços para continuar o fluxo de execução das suas operações. É muito comum encontrar pontos de falha que quebrem o fluxo e abandonem o objeto da finalidade da operação. Sabendo disso é importante ter ferramentas para mitigar os problemas e reduzir a sua incidência no ambiente de produção.
Mensagens bem formatadas, logs centralizados, Ids únicos associativos, métricas, alertas e dashboards são algumas ferramentas que podem nos ajudar com rastreabilidade.