Você está rastreando um bug durante a produção. Você olha através dos logs. A única coisa que você precisa não está lá… Beco sem saída. Alguns anos atrás, eu estava acompanhando um problema de produção com um servidor que acionou uma solicitação para uma leitura de banco de dados devido a falhas de cache . Isso disparou nosso custo devido ao alto volume de leitura. Infelizmente, não havia como saber o que desencadeou isso, pois não havia registro de falhas de cache.

O outro lado disso é que adicionar o registro aqui ajudaria a rastrear a falta de cache, mas teria disparado nossos custos de ingestão de registro. O armazenamento de log é incrivelmente caro. Isso é algo que eu me deparo muito; um desenvolvedor que precisa adicionar um log à produção precisa passar por PR, aprovação, mesclagem, CI/CD etc., apenas para descobrir que outro log é necessário. Em nossa equipe, apelidamos isso de ciclo da morte CI/CD. Adoramos o processo básico, mas ele não foi projetado para ser usado como um “depurador de pobre”.

É uma dor que todos nós sentimos. A observabilidade do desenvolvedor é o nome de uma família de ferramentas projetadas para resolver esse problema. As ferramentas de observabilidade existentes foram projetadas com o DevOps em mente, a observabilidade do desenvolvedor muda a observabilidade para o ciclo de vida de desenvolvimento de software. Neste artigo, explicarei o que são, como são construídos, o que oferecem e como escolher aquele que atende às suas necessidades (sem endossar ferramentas específicas).

Um novo mundo complexo

O mundo do software de hoje é bem diferente daquele que tínhamos quando comecei a programar. Quando eu era um jovem programador, monitorar seu servidor de produção significava caminhar e chutar o hardware para ouvir o disco rígido girar. “Sim, está funcionando.”

Isso obviamente não é mais sustentável. Nossa escala moderna simplesmente não permite isso. Agora temos a equipe de DevOps protegendo a produção – isso é bom. Desde que adotamos o DevOps, contratamos SREs, implementamos CI/CD, etc., a produção se tornou muito mais estável e as startups escalaram com muito mais eficiência do que nunca.

Mas os bugs de produção ainda estão aqui. O progresso que fizemos como indústria tem uma desvantagem significativa, pois esses bugs de produção são MUITO mais difíceis de rastrear do que eram no passado. A escala dificulta. Nuvem, orquestração de contêineres, sem servidor , etc., nos permite implantar centenas ou milhares de instâncias imediatamente. Isso permite capacidade de resposta, confiabilidade e flexibilidade como nunca antes, mas também apresenta problemas de simultaneidade como nunca antes. A corrupção de dados em escala devido a um bug ou configuração incorreta é desenfreada. Apenas uma parte de nossa produção está acessível para nós – isso torna a depuração ainda mais difícil.

Muito poucos desenvolvedores usam ferramentas de observabilidade e monitoramento. A maioria dos fornecedores de ferramentas de observabilidade cria seus produtos com o DevOps em mente e não visa engenheiros. Faz sentido: o DevOps lida com a produção. Mas a nova geração de ferramentas apresenta uma opção: e se você pudesse depurar problemas diretamente na produção?

E se você pudesse fazer isso sem nenhum risco?

O que é observabilidade do desenvolvedor?

A observabilidade do desenvolvedor é um novo pilar da observabilidade adaptado para as necessidades dos desenvolvedores. Ao contrário das soluções típicas de observabilidade, ele é direcionado diretamente aos desenvolvedores e não ao DevOps. Como tal, ele fornece uma conexão direta entre o código-fonte e a produção observável.

A observabilidade do desenvolvedor inclui as duas propriedades distintas a seguir:

  • Com base nas solicitações do usuário
  • Funciona com código fonte

As ferramentas típicas de observabilidade colocam a instrumentação em todo o aplicativo – por exemplo, em cada ponto de entrada de serviço da Web e geralmente mais profundo. Essas ferramentas usam a instrumentação para amostrar dados e enviar informações. Como tal, eles enviam dados de observabilidade para seu servidor de gerenciamento. 

As ferramentas de observabilidade do desenvolvedor não fazem nada por padrão. Um desenvolvedor precisa adicionar explicitamente observabilidade a uma linha (ou linhas) de arquivo de origem específica. Funciona em modo “puxar”.

Uma boa analogia seria que a observabilidade do desenvolvedor é como um depurador, enquanto as ferramentas de observabilidade atuais são como um criador de perfil. Quando você executa com um depurador, ele não faz muito até que você adicione pontos de interrupção para extrair informações. Um criador de perfil constantemente obtém informações durante a execução. Ambos são muito úteis e atendem a diferentes casos de uso.

Registro sob demanda

O registro em produção pode ser inestimável no rastreamento de problemas relacionados a threads. Por causa da escala de produção, alguns problemas de simultaneidade só aparecem lá.

Infelizmente, o registro de produção extensivo não é algo que podemos fazer de forma realista para a maioria dos casos de uso. Se adicionarmos um log em cada entrada/saída de método, nossos logs irão explodir. Eles se tornarão ilegíveis, dispararão nossos custos de armazenamento e diminuirão o desempenho do servidor. Adicionar alguns logs a um servidor específico pode fazer uma grande diferença no processo de depuração sem um impacto perceptível nos logs em geral.

É aqui que as ferramentas de observabilidade do desenvolvedor podem intervir. Um recurso típico dessas ferramentas é a capacidade de adicionar um novo log à produção sem alterar o código. Um desenvolvedor pode adicionar um logon nos pontos de entrada e saída do método diretamente em seu IDE. Como os loggers