É essencial entender, contudo, que observabilidade difere significativamente do conceito de "monitoramento", conforme já discuti em algumas lives e artigos anteriores no blog:

💡 Monitoramento é querer saber as respostas para perguntas específicas, observabilidade é querer saber as respostas para perguntas que ainda não foram feitas.

Em suma, enquanto o monitoramento se preocupa em verificar o estado atual de elementos como memória ou filas em uma aplicação específica, a observabilidade permite teorizar sobre o comportamento da aplicação e usar dados de telemetria para validar ou refutar essas teorias. Questões como: "Será que a lentidão está afetando somente usuários em São Paulo ou é um problema geral? Será que impacta apenas clientes VIP ou está relacionado a um método de pagamento específico?" são exemplos do escopo da observabilidade.

O Papel do APM Nessa Discussão

Recentemente, deparei-me com um post em uma rede social que me fez lembrar do equívoco comum de considerar observabilidade e APM (Application Performance Management) como sinônimos:

A postagem dizia: “Eu tenho trabalhado com observabilidade (anteriormente conhecida como APM) por alguns anos...”

Para deixar claro: eu não conheço essa pessoa e não conheço a solução que ela vende, e respeito muito todas as pessoas que trabalham nessa empresa e são atuantes no projeto OpenTelemetry.

No entanto, tenho que discordar:

💡 Observabilidade não é o que antes era conhecido como APM

A observabilidade mantém-se como a capacidade de explorar dados de telemetria, formulando e respondendo perguntas. Já o APM, por outro lado, oferece visualizações e insights específicos para questões comuns, como identificar os endpoints mais lentos ou as queries SQL que mais impactam o desempenho.

O APM é extremamente útil, mas equiparar observabilidade a APM é um equívoco que pode ser prejudicial tanto para quem extrai valor do APM quanto para quem busca compreender a observabilidade em sua plenitude.

Neste sistema de armazenamento de logs, eles geralmente passam por compressão para reduzir os custos de armazenament, e indexação para facilitar a busca e recuperação posterior. Mesmo depois de tudo isso, muitos desses registros podem nunca mais serem vistos ou consultados novamente. Com tudo isso em mente, não preciso ser um mágico ou vidente para adivinhar que o maior custo que você tem em sua solução de observabilidade está relacionado aos logs.

💡 E se eu te dissesse que você pode reduzir boa parte de seus custos de observabilidade utilizando uma estratégia muito simples?

Ao analisarmos nossos registros de logs, fica claro que o papel mais importante da maioria deles é informar quando um determinado evento ocorreu. Uma vez armazenados, agregamos essas informações em tempo de consulta para saber quantas vezes o evento aconteceu em um determinado período de tempo. E é exatamente para isso que temos outro sinal: métricas. Elas são armazenadas geralmente em um banco de dados temporal, onde o nome do evento é armazenado apenas uma vez, e os diferentes valores em cada intervalo de tempo são armazenados com um alto grau de compressão. O resultado é que cada ocorrência de um evento ocupa, estatisticamente, menos de 1.5 bytes, enquanto o registro do evento de log armazenará tanto a representação em texto puro quanto os índices utilizados para busca, resultando em um custo de armazenamento muito superior.

💡Cada ocorrência de um evento ocupa, estatisticamente, menos de 1.5 bytes como métrica. Ao calcular o custo de uma solução de logs, usa-se 200 bytes para cada ocorrência como ponto de partida.

Não estou dizendo que TODOS os eventos devem ser migrados de logs para métricas, mas muitos dos eventos que armazenamos hoje podem sim ser convertidos.

Como fazer a conversão

A melhor forma de se fazer a conversão é ao alterar a instrumentação no seu próprio código. Por exemplo, onde antes víamos algo assim…

log.Info("chamada http recebida para / , status é 200")

… agora temos algo assim ao usar a API de métricas do OpenTelemetry:

// em um código de inicialização:
contadorHTTP, err := meter.Int64Counter(
        "http.calls",
        metric.WithDescription("Quantidade de vezes que recebemos uma chamada HTTP."),
    )

// no nosso handler HTTP, adicionamos 1 ao contador
contadorHTTP.Add(r.Context(), 1, metric.WithAttributes(semconv.HTTPStatusCode(200))))

A segunda forma de se fazer isso é utilizar o OpenTelemetry Collector para converter de um sinal para o outro. Por exemplo, pode-se utilizar o count connector juntamente com um filtro, para que apenas eventos pré-selecionados sejam convertidos em métricas. Todos os outros eventos continuam como logs:

receivers:
  otlp:
    protocols:
      grpc:

processors:
  filter/remove-common-events:
    logs:
      log_record:
        - 'IsMatch(body, ".*http call made to route.*")'

  filter/retain-common-events:
    logs:
      log_record:
        - 'not IsMatch(body, ".*http call made to route.*")'

exporters:
  logging/metrics:
    verbosity: detailed
  logging/logs:

connectors:
  count:
  forward:

service:
  pipelines:
    # a pipeline principal, direcionando os dados para as outras pipelines de logs
    logs:
      receivers:
        - otlp
      exporters:
        - forward

    # filtra os eventos comuns, mantendo o restante
    logs/everything-else:
      receivers:
        - forward
      processors:
        - filter/remove-common-events
      exporters:
        - logging/logs

    # mantem apenas os eventos comuns
    logs/common-events:
      receivers:
        - forward
      processors:
        - filter/retain-common-events
      exporters:
        - count

    # converte logs em metricas
    metrics/count-common-events:
      receivers:
        - count
      exporters:
        - logging/metrics

Com isso, se detectarmos que o evento com o texto “http call made to route” é muito comum em nosso ambiente, podemos convertê-lo em métricas diretamente no Collector. Para testar, podemos utilizar o telemetrygen para gerar dois tipos de registros de logs, um que vai ser convertido pra métricas, e outro que não:

telemetrygen logs --otlp-insecure --logs 10 --body "http call made to route '/', status=200"
telemetrygen logs --otlp-insecure --logs 10 --body "some other message"

Entre um comando e outro, veja as métricas internas do nosso Collector, pra ter certeza de que logs foram convertidos para métricas e de logs que continuaram sendo logs. Dê uma olhada nas métricas otelcol_exporter_sent_metric_points , otelcol_exporter_sent_log_records e otelcol_receiver_accepted_log_records:

• ao rodar o primeiro comando, o Collector deve ter aceito 10 registros de log, exportado 10 pontos de dados de métricas, e nenhum log

• ao rodar o segundo comando, o Collector deve ter aceito 20 registros de log, exportado 10 pontos de dados de métricas, e 10 registros de log

Conclusão

Muito provavelmente você tem um sistema que emite logs, mas não emite métricas. Por este motivo, você acaba usando ferramentas de log quando seu interesse está na verdade em métricas. Porém, os custos acabam sendo muito mais altos do que se o sinal adequado fosse utilizado. A conversão de logs em métricas não só otimiza os custos de armazenamento e transmissão, mas também pode melhorar a eficiência na análise de dados e na detecção de problemas.

Fundamentos de Observabilidade

A observabilidade é a arte e a ciência de tornar sistemas complexos transparentes e compreensíveis. Vai além do monitoramento tradicional, envolvendo a análise profunda do comportamento e da interação de sistemas de software em diferentes cenários. Profissionais dessa área têm a responsabilidade de antecipar problemas antes que afetem os sistemas, garantindo estabilidade e eficiência operacional. No entanto, como é impossível prever tudo, a chave para o sucesso está na instrumentação efetiva dos serviços em operação. Isso permite compreender seu comportamento real em tempo de execução e facilita o diagnóstico durante momentos de estresse.

Para isso, é necessário conhecer os elementos fundamentais da observabilidade: os sinais de telemetria. Saber quais são e quando utilizá-los é essencial. Também é importante compreender as diferenças entre os sinais e como são armazenados, pois muitas decisões do dia a dia estão relacionadas a esses detalhes, como alta cardinalidade, armazenamento colunar, indexação de dados, entre outros temas que fazem parte do repertório de uma pessoa engenheira de observabilidade.

Ferramentas e Tecnologias Chave

O arsenal de uma pessoa engenheira de observabilidade inclui ferramentas de métricas, rastreamento distribuído e logs. Além de conhecer ferramentas específicas utilizadas para o armazenamento desses sinais, como Prometheus, Jaeger, Loki, entre outros, é necessário também saber como esses sinais são gerados: quais bibliotecas de instrumentação podem ser utilizadas? Depois da instrumentação, temos que nos preocupar com as ferramentas de coleta e processamento, como o OpenTelemetry Collector.

A habilidade de implementar e otimizar essas ferramentas é crucial, permitindo a coleta, o processamento e a análise eficiente de dados de telemetria.

Abordagem Analítica e Resolução de Problemas

Profissionais de observabilidade devem possuir uma forte capacidade analítica. Além disso, é importante destacar que eles não são os principais responsáveis por operar serviços de negócios, mas desempenham um papel fundamental ao auxiliar e orientar outros profissionais da empresa, como SREs e engenheiros de software. Dessa forma, é essencial que eles saibam interpretar grandes volumes de dados e transformá-los em insights acionáveis, o que requer uma habilidade analítica apurada. Essa habilidade é vital, pois permite identificar rapidamente problemas e tomar decisões embasadas em evidências confiáveis. Portanto, a capacidade analítica é um atributo fundamental para o sucesso dos profissionais de observabilidade.

Aprendizado Contínuo e Adaptação

O campo de observabilidade ainda está em sua infância e constantemente vemos novidades surgindo. Novas ferramentas, práticas, conceitos e tecnologias estão emergindo regularmente. Para ter sucesso nessa área em constante evolução, é fundamental se manter atualizado por meio de eventos da comunidade, webinars, treinamentos e também por meio da leitura de artigos e pesquisas recentes. Além disso, é essencial estar aberto a novas ideias e experimentos, e praticar constantemente com o objetivo de aprendizado e aprimoramento contínuo. É importante também buscar oportunidades de colaboração com profissionais da área, participando de grupos de estudo e fóruns de discussão para trocar conhecimentos e experiências, como os canais OpenTelemetry BR e Dose de Telemetria no Telegram. Dessa forma, poderemos estar sempre preparados para os desafios e exigências cada vez maiores desse campo promissor.

Impacto Cultural e Educação Transversal

Um aspecto crucial da carreira em observabilidade é o impacto cultural dentro das organizações. Engenheiros de observabilidade desempenham um papel vital na educação de outras equipes, promovendo uma compreensão mais ampla da importância da observabilidade. Eles são os embaixadores desta disciplina, ajudando a integrar práticas de observabilidade em todos os aspectos do desenvolvimento de software e operações.

📚 Leitura recomendada

• Distributed Systems Observability
  Um dos livros mais influentes na área de observabilidade, apesar de já estar um pouco defasado

• Distributed Tracing in Practice
  Poderia ser mais “in practice”, mas ainda assim é um livro interessante para se entender rastreamento distribuído

• Cloud-Native Observability with OpenTelemetry | Packt
  Livro focado em OpenTelemetry escrito por um mantenedor do projeto

• Observability Engineering
  Provavelmente o melhor livro da atualidade nessa área, mas é um pouco dogmático demais em alguns aspectos. Leia com cuidado, filtre os interesses comerciais dos autores, e adapte os conceitos para suas necessidades.

Vídeo original

Falei sobre este tópico em um vídeo disponível no canal do Dose de Telemetria no YouTube. Você pode assistir ao vídeo aqui.

Uma excelente maneira de compreender o que é telemetria é através da analogia com a condução de um carro. Quando dirigimos, uma série de dados como velocidade, aceleração, e desaceleração são constantemente registrados. Esses dados, semelhantes aos gerados por uma aplicação, fornecem insights sobre o desempenho, como a velocidade de processamento ou o número de requisições recebidas por minuto.

Os Tipos Principais de Dados de Telemetria

Logs: Esses são registros de eventos específicos que ocorrem durante a operação da aplicação. Eles são cruciais para o processo de depuração e fornecem um relato detalhado do que aconteceu e quando.

Métricas: Representam um resumo agregado de como a aplicação está funcionando. Por exemplo, elas podem quantificar o número atual de visitantes de um site. Métricas podem ser representadas de várias formas, incluindo contadores que só aumentam ou valores que variam.

Rastros: Estes são conjuntos de informações que ajudam a entender o percurso de uma requisição específica através de vários processos ou microserviços. Eles são fundamentais para compreender como as diferentes partes de uma aplicação interagem.

Outros Sinais

Existem também outros tipos de dados de telemetria que são importantes para entender o desempenho e o comportamento de uma aplicação, entre eles:

Eventos: São registros de ocorrências significativas que ocorrem durante a execução da aplicação. Eles podem ser utilizados para identificar eventos específicos e analisar seu impacto no sistema.

Perfis: Permitem o monitoramento e a análise do desempenho de uma aplicação ao longo do tempo. Eles fornecem informações detalhadas sobre a utilização de memória, tempo de execução de funções e outros aspectos relacionados ao desempenho.

Erros (Stack Traces): São registros que capturam informações sobre exceções e erros que ocorrem durante a execução da aplicação. Esses registros são essenciais para identificar e corrigir problemas no sistema.

Esses tipos adicionais de dados de telemetria complementam os logs, métricas e rastros mencionados anteriormente, fornecendo uma visão mais completa e detalhada do desempenho e do estado da aplicação.

Monitoramento vs. Observabilidade

Monitoramento

O monitoramento diz respeito a ter respostas para perguntas conhecidas sobre uma aplicação. Por exemplo, receber um alerta quando a CPU de um servidor atinge 90% de sua capacidade. É uma forma proativa de estar ciente do estado atual do sistema.

Observabilidade

Por outro lado, a observabilidade se refere à capacidade de entender o que está acontecendo em um sistema com base nos dados coletados, incluindo a telemetria. Ela é crucial para diagnosticar problemas não previstos durante o desenvolvimento.

Conclusão

Em resumo, a telemetria é a matéria-prima para o monitoramento e a observabilidade em tecnologia da informação. Ela fornece os dados necessários para compreender profundamente o funcionamento de uma aplicação, permitindo a otimização e a manutenção eficiente do sistema.

Vídeo original

Falei sobre este tópico em um vídeo disponível no canal do Dose de Telemetria no YouTube. Você pode assistir ao vídeo aqui.

Em alguns casos, isso pode até precipitar falhas que de outra forma poderiam ter sido evitadas: já tive uma experiência no passado em que a escrita síncrona de logs estava causando uma degradação significativa de performance em um sistema de alta concorrência.

Métricas

Em contraste com logs ou rastros, as métricas são geralmente menos invasivas. Elas são predefinidas e agregadas, o que minimiza o impacto no desempenho do sistema. No entanto, problemas podem surgir durante a atualização concorrente dos contadores ou na transmissão desses dados: diferentes bibliotecas utilizam diferentes técnicas que podem não ser as mais corretas para seu caso de uso.

Um dos maiores desafios ao utilizar sistemas do tipo pull, como o Prometheus, é encontrar um equilíbrio adequado entre a frequência das requisições feitas pelo servidor ao cliente que está expondo as métricas e a quantidade adequada de métricas que o cliente deve expor. É importante garantir que o servidor não faça requisições tão frequentes que sobrecarreguem o cliente, nem que o cliente exponha um número excessivo de métricas que possa impactar negativamente o desempenho do sistema.

Já em sistemas push, como o OTLP (OpenTelemetry Protocol), é importante considerar que vários clientes podem enviar dados para o mesmo servidor simultaneamente. Portanto, o servidor precisa ter capacidade para receber todos esses dados.

Rastros

Os trechos (spans) em rastros (traces) representam um desafio maior. Por serem sinais de alta resolução, sem agregação, eles utilizam armazenamento de dados em memória e podem aumentar a carga no sistema. A gestão eficaz desses rastros é crucial para minimizar seu impacto. Estratégias como amostragem (sampling) ou envio de dados em lotes (batching) podem ajudar nessa tarefa. Mas ainda assim, quanto mais trechos são utilizados em um determinado serviço, maior o número de dados que são mantidos em memória: trechos apenas são enviados para o destino quando são finalizados, o que geralmente acontece somente no final da requisição.

Logs

Já quando falamos de logs, nossa maior preocupação é com I/O: conseguimos escrever todos os registros na nossa saída de log? Hoje em dia, a prática comum é de escrever em stdout e stderr, mas essas saídas têm performance boa o suficiente para o volume de registros que você está esperando? Aqui, a saída mais sensata é converter eventos que iriam para o registro de logs em métricas, quando podem ser agregados, ou em trechos de um rastro, quando o evento pertence a uma transação específica.

Cuidado com o Desperdício

Um aspecto crítico é o consumo de rede e o armazenamento de dados de telemetria. Na minha experiência, muitos dados coletados acabam não sendo utilizados, o que resulta em desperdício de recursos. Portanto, é importante não apenas considerar como a telemetria é gerada e coletada, mas também como ela é usada. Se os dados de rastreamento distribuído são apenas armazenados e raramente lidos, pode ser interessante aplicar uma estratégia mais forte de amostragem, para que menos dados sejam enviados e armazenados. Além disso, reduzir o número de dimensões de uma métrica pode diminuir significativamente o número de séries temporais no banco de dados. E converter logs em métricas certamente vai reduzir muito seus custos de rede e armazenamento!

Conclusão

A telemetria é essencial para diagnóstico e otimização de sistemas, mas seu uso deve ser cuidadosamente gerenciado para evitar impactos negativos adicionais, especialmente em sistemas críticos e de alta concorrência.

Vídeo original

Falei sobre este tópico em um vídeo disponível no canal do Dose de Telemetria no YouTube. Você pode assistir ao vídeo aqui.

Você poderia escrever uma música no estilo musical do Gabriel O Pensador, usando Observabilidade como tema central?

Claro que não é um Gabriel O Pensador de verdade, mas juro que fiquei bem surpreso com o resultado!

Observa Aí, Dev

Ei, dev, já parou pra observar?
No mundo do código, tem mais pra monitorar.
Logs espalhados, contando a história,
De bugs escondidos, perdidos na memória.
Trace cada passo, veja a viagem,
De um request perdido na paisagem.
Microserviços, um labirinto sem fim,
Um trace aqui, outro ali, e chega em mim.

(Refrão)

Observa aí, no mundo virtual,
Cada linha de código, um sinal.
Métricas e logs, nossa bússola fiel,
No mar de código, é o nosso papel.

(Verso 2)

Monitora o sistema, olho no painel,
CPU, memória, tudo nele é tão fiel.
Latência e erros, um gráfico a subir,
Alarme toca, é hora de agir.
No mundo cloud, tudo é tão volátil,
Um crash aqui, acolá, algo tão sutil.
Mas com observabilidade, a gente vê,
O que está por trás do código, o que faz o sistema de pé.

(Refrão)

Observa aí, dev, na tua tela,
Cada alerta, uma história, uma aquarela.
Dashboard iluminado, dados a fluir,
Na arte de codar, a gente aprende a prever.

(Ponte)

Na nuvem, na terra, no código, na guerra,
Cada linha que escreve, uma nova era.
Observabilidade, nossa lanterna no escuro,
Ilumina o caminho, no código seguro.

(Refrão)

Então observa, amigo, não deixa passar,
Cada bug, cada log, um lugar para olhar.
No mar de informações, a gente aprende a nadar,
Com observabilidade, a gente aprende a jogar.

(Outro)

E aí, dev, viu como tudo se conecta?
Na tela, no código, na métrica perfeita.
Observa, melhora, e segue o caminhar,
No mundo do código, a gente nunca para de sonhar.