Observabilidade

As aplicações, por muito tempo, eram construídas de maneira centralizada, os famosos monólitos, entretanto, ao longo dos últimos anos, a área de tecnologia vem mudando bastante.

As aplicações usam cada vez mais ferramentas e abordagens distribuídas, como Containers, Kubernetes, Microservices e Serverless, por exemplo. Essas tecnologias proporcionam diversas vantagens, a escalabilidade sendo uma das mais relevantes. Porém, introduziram complexidade adicional, fazendo com que as falhas sejam mais difíceis de prever, detectar e solucionar problemas.

Buscando resolver esse problema surge, na Engenharia de Software, o conceito de Observabilidade, buscando fornecer um nível de introspecção e ajudar as pessoas a raciocinar sobre os estados internos de seus sistemas.

Observabilidade é a habilidade de entender o que está acontecendo dentro do seu sistema com base em suas saídas. Isso significa que você deve saber explicar qualquer estado em que seu sistema possa entrar. Por exemplo: estado de falha, estado de lentidão etc. Busca alcançar uma melhor compreensão de como o software está operando.

Pilares da Observabilidade

Para tentar alcançar o maior entendimento do que está acontecendo no seu sistema, existem 3 principais pilares que, por si só, não fazem um sistema observável, mas relacionando eles se tem um entendimento muito bom dos processos do seu sistema.

Logs

Os logs são registros imutáveis que possuem data/hora de eventos que ocorrem em um sistema, eles fornecem contexto sobre o que está acontecendo no sistema e podem ser utilizados para identificar problemas e rastrear sua origem.

Podemos considerar então que as mensagens de logs representam os vários eventos que ocorrem nos sistemas, podendo ser informativos ou até mesmo registrar um problema que aconteceu em seu sistema.

Métricas

Quando pensamos em métricas para arquitetura de microservices, devemos conhecer o método RED. Esse método define as três principais métricas que devemos medir em microservices. São as métricas básicas que recebemos por padrão nas principais soluções de APM do mercado. As métricas RED são:

RATE

Número de requisições por segundo que seu serviço está atendendo.

ERROR

Número de requisições com falha por segundo.

DURATION

Tempo médio que o serviço gasta para processar cada requisição.

Tracing

Rastreamento distribuído (ou Distributed tracing) é um conjunto de técnicas, padrões e práticas que tem como principal objetivo mostrar o fluxo por onde passou uma requisição, se ela foi atendida e quanto tempo levou para a requisição ser atendida.

Vamos imaginar que esse usuário está enfrentando uma lentidão para receber a resposta de sua requisição. Sem usar distributed tracing (por exemplo, olhando os logs isolados de cada microservice) ficará difícil identificar rapidamente onde está ocorrendo o gargalo, onde podem ocorrer erros etc.

Com muitos serviços envolvidos em apenas uma única requisição, é difícil também você reportar as equipes responsáveis por esses componentes sem saber identificar o problema, gerando lentidão na resolução do problema.

Exemplo de tracing no New Relic:

Ferramentas de Observabilidade

Existem diversas ferramentas para lidar com cada pilar da observabilidade, umas fazem melhor uma coisa, outras tem melhor desempenho, etc. Você deve avaliar qual se encaixa melhor para o seu cenário e combiná-las.

A seguir listei algumas das ferramentas de observabilidade mais utilizadas no mercado

New Relic - https://newrelic.com/

Grafana - https://grafana.com/

Prometheus - https://prometheus.io/

Data Dog - https://www.datadoghq.com/