Observabilidade: Prometheus e Grafana para sistemas distribuídos

Apresentando o curso e o instrutor

Olá! Sejam bem-vindas e bem-vindos ao curso de Observabilidade com Prometheus e Grafana. Antes de mais nada, vou me apresentar. Meu nome é Mário.

Audiodescrição: Mário é um homem branco, de cabelo escuro. Ele está no sótão de sua casa, em um espaço apertado, com um teto baixo que quase encosta em sua cabeça.

Explicando objetivos do curso e próximos passos

Neste curso, vamos aprender em mais detalhes quais são as ferramentas frequentemente mencionadas no contexto de observabilidade e que são essenciais para construirmos uma observabilidade robusta e funcional.

Antes de mais nada, vamos entender melhor as diferenças entre monitoramento e observabilidade, para então nos aprofundarmos nessas ferramentas. Precisamos compreender a estrutura da observabilidade e organizá-la, para que possamos entender as ferramentas que proporcionarão observabilidade. Isso faz sentido. Vamos prosseguir.

Nos vemos no próximo vídeo.

Apresentando os três pilares

No vídeo anterior, dissemos que mostraríamos quais são os pilares da observabilidade, o que são exatamente e como podemos registrá-los. Vamos mostrar na nossa tela, que estamos compartilhando, quais são esses três pilares.

Os três pilares são: métricas, logs (registros) e traces (rastreamentos). Vamos entender cada um deles e como podem nos ajudar a obter uma boa observabilidade.

Detalhando métricas de observabilidade

Em relação a métricas — que é onde vamos trabalhar mais neste curso, porque o Prometheus está muito focado nessa parte e, por isso, é bastante robusto para entregar métricas — que tipos de informação elas fornecem? Exemplos:

• Requisições por segundo;
• CPU;
• Memória;
• Quanto de networking (rede) está sendo utilizado;
• Quanto de I/O (entrada/saída) está sendo utilizado.

Há muitas informações, e falaremos mais sobre isso adiante, incluindo alguns antipadrões que devemos evitar. Este é o primeiro pilar dos três pilares.

Explicando logs com analogia do avião

O próximo pilar são os logs (registros): eles registram eventos da aplicação. Para explicar logs, gostamos de usar a analogia do avião. Quando viajamos de avião, o piloto se comunica com a torre de controle informando: “Estamos indo nesta direção, nesta posição; o avião subirá em 5 minutos e estamos prontos para decolar.” A torre de controle responde: “Autorizado a voar.” Assim, ficam determinados todos os passos que serão executados para efetuar a decolagem.

Da mesma forma, os logs registram os eventos da aplicação. Por exemplo, quando a aplicação realiza uma transação, registramos:

• O horário;
• O ID dessa transação;
• O que ocorreu: se foi uma transação mal realizada, se houve um erro, apenas um aviso, se o ID não existe ou se foi simplesmente uma transação bem-sucedida.

Os logs fornecem sinais e eventos que podem ser negativos ou positivos para a aplicação. São uma base fundamental; sem eles faltará muita informação na observabilidade.

Analisando traces de execução

Quando falamos do terceiro pilar da observabilidade, falamos de traces (rastros de execução). São muito importantes; podemos usar a analogia de um serviço de entregas, no qual rastreamos um pacote. Ao comprar um produto eletrônico para entrega, conseguimos rastreá-lo e ver exatamente para onde vai, onde parou e por que parou. Da mesma forma, a trace (rastro de execução) nos fornece o caminho, o percurso pelo qual a request (requisição) passa até chegar ao seu ponto final, que pode ser a pessoa cliente ou outra aplicação. Obtemos todos esses dados e essas informações cruciais, fundamentais para determinar um problema.

Vamos apresentar um exemplo. Vamos imaginar que, por alguma razão, fazemos uma request (requisição) a um banco de dados. Nesse banco de dados, a request (requisição) começou a demorar muito para responder. Vemos que ela passou pela nossa aplicação, chegou ao banco de dados, demorou a responder e, depois, finalizamos. O processamento da nossa aplicação levou, digamos, alguns milissegundos, mas a resposta do banco de dados levou dois segundos, um tempo enorme. Isso provocou o acúmulo de muitas solicitações.

Correlacionando métricas e traces para diagnosticar problemas

Por alguma razão, devido a esse acúmulo de requests (requisições), o uso de CPU aumentou. Existe uma conexão muito forte entre as métricas e as traces (rastros de execução). Por exemplo, identificamos que esse banco de dados está demorando muito, e começaram a se acumular muitas solicitações na nossa aplicação. Vimos que as métricas de CPU estão aumentando muito e isso coincide exatamente com aquela request (requisição) lenta ao banco de dados. Ao observar e analisar, percebemos que uma coisa coincide com a outra.

Nossa aplicação começa a usar mais CPU, passa a sofrer limitação de taxa (throttling), e as solicitações passam a demorar mais do que o esperado, causando indisponibilidade no serviço ou uma experiência ruim para a pessoa cliente.

Assim, esses três pilares sempre convergem para que possamos identificar o problema o mais rápido possível.

Introduzindo a diferença entre monitoramento e observabilidade

No vídeo anterior, falamos sobre entender a estrutura da observabilidade e a diferença entre monitoramento e observabilidade.

Vamos fazer uma analogia. Imagine que você é responsável por um sistema ou uma aplicação e precisa cuidar dessa aplicação. Ela está sendo executada em um servidor ou em dois. Em determinado momento, percebemos que clientes que acessam esse app (aplicativo) começaram a relatar que ele não funcionava. Ao revisar a aplicação, constatamos que, de fato, ela não estava funcionando durante o teste. Em seguida, analisamos as métricas, os logs (registros) e as traces (rastros de execução) e tudo parecia estar em ordem. Havia métricas de CPU, RAM e vários outros tipos de métricas e, aparentemente, tudo funcionava. Nesse caso, temos monitoramento.

A observabilidade é diferente. A observabilidade nos ajuda a identificar qual é o problema que estamos enfrentando. O monitoramento apresenta indícios de que algo está acontecendo; a observabilidade explicita o problema em si. Assim, conseguimos definir com clareza o que é monitoramento e o que é observabilidade.

Construindo uma analogia com hospitais

Vamos trazer outra analogia para entendermos melhor monitoramento e observabilidade. Vamos criar uma analogia com hospitais, por exemplo. Digamos que o monitoramento tradicional seria um exame anual.

Temos dados de vários sinais vitais do corpo, como a pressão, sinais e informações do coração e dos pulmões. São indicadores que mostram se estamos bem em determinado ano ou se há algum indício de problema.

Na observabilidade, o cenário é diferente. Teríamos, por exemplo, uma UTI (Unidade de Terapia Intensiva) em casa funcionando 24 horas por dia (24/7).

Evidenciando limites do monitoramento e benefícios da observabilidade

Em um modelo tradicional de monitoramento, não identificaríamos se estivéssemos sofrendo um ataque cardíaco, porque contaríamos apenas com indícios anuais. E se o ataque cardíaco acontecesse agora, por exemplo? Esses dados não ajudariam muito.

Na observabilidade, por outro lado, teríamos diversos relatórios e até vários aparelhos conectados a nós 24 horas por dia. Assim, teríamos informações sobre o corpo o tempo todo, com dados que mostrariam quando começou a oscilar e quando começou a aumentar o sinal que pode nos prejudicar e causar um ataque cardíaco.

Essa é a analogia que queremos compartilhar com vocês sobre a diferença entre monitoramento e observabilidade. Mas, Mário, isso quer dizer que não precisamos de monitoramento? Não. Precisamos de ambos.

No próximo vídeo, vamos mostrar, na prática, com mais detalhes, o que queremos dizer com essas diferenças e por que isso é importante. Vamos ver isso na prática.