Registro do OpenTelemetry: uma introdução

O registro de OTel oferece às equipes de TI uma estrutura de mapeamento unificada e inequívoca para converter dados de log de diferentes fontes, sistemas e formatos em um modelo único e neutro em termos de linguagem, preservando os significados semânticos originais.

Com um modelo de dados estruturado e independente de fornecedores, as ferramentas de observabilidade podem analisar logs com mais facilidade e confiabilidade, anexar metadados e correlacionar logs com métricas e rastreamentos para uma visibilidade profunda de ponta a ponta.

O registro de OTel permite que empresas alternem e misturem backends de observabilidade sem reinstrumentalizar toda a arquitetura de TI, razão pela qual se tornou o padrão do setor para instrumentação em sistemas nativos da nuvem modernos. Esses recursos ajudam as equipes de TI e os engenheiros de confiabilidade de sites (SREs) a evitar as lacunas de observabilidade e os problemas de fragmentação de dados que ocorrem quando cada fornecedor, stack e dispositivo tem seu próprio esquema de registro e protocolos de transmissão.

O registro de OTel também facilita a correlação automática de sinais cruzados, o que melhora drasticamente a depuração e reduz o lock-in com fornecedor de observabilidade.

Os logs do OpenTelemetry são um componente vital do OpenTelemetry. O OpenTelemetry é um framework de observabilidade de código aberto que inclui uma coleção de kits de desenvolvimento de software (SDKs) , interfaces de programação de aplicativos (APIs) independentes de fornecedores e outras ferramentas para instrumentação de aplicações, sistemas e dispositivos.

O código de instrumentação utilizado varia muito, e nenhum provedor comercial oferecia uma ferramenta capaz de coletar dados de todos os aplicativos e serviços em rede. Essa lacuna de funcionalidades tornava difícil (e, muitas vezes, impossível) para as equipes coletar dados de diferentes linguagens de programação, formatos e ambientes de tempo de execução.

As abordagens tradicionais de observabilidade também tornavam a mudança da infraestrutura e dos componentes de back-end um processo demorado e trabalhoso.

Se, por exemplo, uma equipe de desenvolvimento quisesse trocar as ferramentas de back-end, teria que reinstrumentalizar completamente seu código e configurar novos agentes (componentes de software que executam tarefas automatizadas de construção e lançamento) para enviar dados de telemetria aos novos servidores. As abordagens fragmentadas criaram silos e confusão, dificultando a resolução eficaz de problemas de desempenho.

O OpenTelemetry representou um avanço significativo nas ferramentas de observabilidade porque padronizou a forma como os dados de telemetria são coletados, analisados e transmitidos para plataformas de back-end. Ele forneceu uma solução de código aberto (baseada em padrões orientados pela comunidade) para coletar dados sobre o comportamento e a segurança do sistema, ajudando as equipes a simplificar o monitoramento e a observabilidade em ecossistemas distribuídos.

O registro do OpenTelemetry depende de vários componentes cooperantes que criam, estruturam, transportam e entregam registros de log como parte de um pipeline de observabilidade unificado. Entre eles:

Um registro de log é uma estrutura de dados central que representa um único evento de log no OpenTelemetry. Ele segue um modelo de dados padrão que define campos e semântica, para que os logs de diferentes linguagens e sistemas possam ser interpretados de forma consistente pelos back-ends.

Os registros de log aparecem como linhas estruturadas em uma planilha descrevendo um evento e respondendo a perguntas básicas, como "o que aconteceu", "quando isso aconteceu", "qual é a importância" e "de onde veio".

O modelo de dados de log é o modelo comum que todo registro segue, em todas as linguagens e sistemas. Ele define quais campos de nível superior existem e o que cada um deles significa.

Um modelo de dados de log típico exige que os registros incluam:

• Um registro de data e hora e um registro de data e hora observada (quando o evento aconteceu e quando foi visto)

• Números e textos de gravidade (também chamados de nível de log), que descrevem o nível de gravidade de um evento

• O corpo (a mensagem de log principal, geralmente uma string curta ou um objeto JSON)

• Atributos, que adicionam detalhes mais refinados sobre cada evento (como detalhes do usuário ou de HTTP)

• Informações de recursos que identificam o serviço emissor e o ambiente de implementação

• IDs de rastreamento e IDs de intervalo que vinculam o evento a uma solicitação específica (simplifica a correlação de dados)

A estrutura que os modelos de dados impõem transforma logs de diferentes serviços e tecnologias em entidades de telemetria vastas e consultáveis, que têm aparência e comportamento iguais quando entram no pipeline de observabilidade. Os modelos de dados de log permitem que as equipes de TI correlacionem logs com rastreamentos, agrupem-nos por serviço ou usuário e executem os mesmos tipos de consultas em todo o ambiente de TI, em vez de lidar com uma variedade de formatos de log incompatíveis.

E como o modelo de log é aberto e orientado pela comunidade, a instrumentação e os pipelines de log do OTel são portáteis (não vinculados a um único produto de software como serviço (SaaS) ou agente proprietário). Eles funcionam em todos os frameworks e plataformas, o que é particularmente valioso em ambientes de microsserviços poliglotas.

Um logger é o objeto que grava registros de log, semelhante às instâncias de logger em outros frameworks de registro (como Java e Python). Quando uma plataforma de observabilidade envia um comando "registrar esse erro" ou "registrar essa mensagem de informação", está enviando a mensagem para um logger.

Diferentes partes de uma aplicação ou sistema podem exigir seus próprios loggers (por exemplo, um para "checkout" e outro para "pagamentos"), mas todas seguem as mesmas regras para gerar logs.

Os loggers são obtidos de um provedor de loggers, que é responsável por criar loggers e configurá-los com o pipeline, os atributos e os exportadores corretos.​ Quando o código de software solicita um logger, o provedor fornece um que já está devidamente configurado.

Esse design permite que diferentes partes de um sistema usem diferentes loggers que ainda compartilham uma configuração comum e são todos gerenciados centralmente pelo provedor de loggers. Isso também facilita para as equipes de TI a troca de implementações e o ajuste do comportamento de registro globalmente sem modificar cada local de chamada.

O coletor do OTel Collector é um serviço separado que recebe, processa e exporta dados de telemetria (incluindo registros de log) de muitas fontes. As aplicações enviam seus logs (e rastreamentos e métricas) para o coletor, que pode receber dados em diferentes formatos, padronizá-los e, em seguida, enviá-los para um ou mais back-ends.

Os coletores são compatíveis com pipelines de logs dedicados, criados em torno de três subcomponentes principais: receptores, processadores e exportadores.

Os receptores realizam a ingestão de logs de várias entradas, como fluxos do OpenTelemtetry Protocol (OTLP) e arquivos de log de receptores de rastreamento de arquivos. Os processadores realizam operações como processamento em lote, modificação de atributos, enriquecimento de contexto (adicionando metadados de pods do Kubernetes, por exemplo), filtragem e amostragem em registros de log. Os exportadores dentro do coletor, então, encaminham os logs processados para um ou mais destinos.

Os exportadores de registros de log ficam em um coletor do OTel ou em um SDK de aplicação e definem onde e como os dados de telemetria são entregues aos sistemas de back-end.

Depois que o SDK de logs cria e processa um registro de log, o exportador codifica o modelo de dados de log em um protocolo ou formato específico e envia o registro para um "consumidor" posterior. Os consumidores podem incluir, por exemplo, coletores do OTel, soluções de observabilidade ou armazenamentos de código aberto.

Os exportadores podem ser baseados em push ou pull e podem ser trocados e combinados para transmitir simultaneamente os mesmos registros de log para diferentes back-ends sem modificar o código da aplicação. A flexibilidade proporcionada pelos exportadores torna mais fácil para as empresas evoluir sua arquitetura de observabilidade à medida que os requisitos mudam.

A API de logs e o SDK de logs funcionam como uma tomada em uma extensão: a API é o tipo de tomada, e o SDK é a extensão que transporta a eletricidade.

As APIs do OpenTelemetry compreendem um conjunto de funções que as bibliotecas de código e registro chamam para criar entradas de registro uniformes. Essencialmente, a API de logs determina a "forma" que um log deve tomar para "se conectar" ao OTel. A API de logs ajuda a garantir que as mesmas chamadas de API funcionem, independentemente do back-end ou fornecedor de observabilidade que a equipe de TI escolher posteriormente.

No entanto, a API é apenas uma interface. Ela não pode decidir para onde os logs vão ou como são enviados. É aí que o SDK do OpenTelemetry (ou SDK de logs) entra em cena.

O SDK de logs pega logs do endpoint da API e faz o trabalho real com eles. Ele recebe registros de log, enriquece-os (adicionando nome de serviço ou ambiente, por exemplo), cria lotes e os prepara para envio. Em seguida, usa exportadores para enviar os logs processados para um coletor ou uma plataforma de log.

Os administradores de logs (também chamados de pontes de logs) conectam bibliotecas de registro existentes (como Log4j, SLF4J ou frameworks semelhantes) ao modelo de dados de log do OpenTelemetry.

Em vez de os desenvolvedores de software chamarem diretamente a API de logs, eles podem configurar o framework de registro existente para usar um adicionador que transforma cada evento de log tradicional em um registro de log do OTel.

As pontes de log também podem injetar contexto de intervalo e rastreamento em registros de log, permitindo a correlação entre logs e rastreamentos mesmo quando o próprio código da aplicação não tem conhecimento dos detalhes de rastreamento.

Os mecanismos de propagação e correlação de contexto são componentes essenciais do registro do OpenTelemetry. Quando um intervalo de rastreamento está ativo, uma ponte de registro ou SDK pode anexar automaticamente a ID de rastreamento atual e a ID de intervalo a cada registro de log emitido.

A correlação ajuda os back-ends de observabilidade a conectar logs a rastreamentos distribuídos que representam a mesma solicitação ou fluxo de trabalho. Essas conexões permitem que as equipes naveguem de uma entrada de log problemática diretamente para um rastreamento que mostra o caminho completo da solicitação. Isso também facilita a análise cruzada de sinais para métricas, rastreamentos e logs que compartilham campos comuns de recursos e contexto.

O OTel fala sobre "tipos" de log de algumas maneiras diferentes: por estrutura, por fonte e por codificação ou protocolo de transmissão.

Os logs estruturados têm um esquema consistente (os mesmos campos, com nomes e tipos de dados estáveis) para que as ferramentas de observabilidade possam analisá-los e consultá-los de forma confiável. Os logs podem ser codificados com JSON ou outro formato, mas o que os torna estruturados é o conjunto previsível de campos de dados.

Os logs semiestruturados contêm alguma estrutura reconhecível (pares de valores-chave ou blobs semelhantes a JSON, por exemplo), mas o esquema não é consistente ao longo do tempo. Eles são mais legíveis por máquina do que o texto de formato livre, mas exigem análise e normalização adicionais para que as equipes possam analisá-los de forma eficaz.

Logs não estruturados são mensagens de texto de formato livre sem um esquema estável (como instruções de impressão ad hoc ou logs de servidor de texto simples). Eles são fáceis para os humanos escreverem e lerem, mas mais difíceis para os sistemas automatizados pesquisarem, correlacionarem e agregarem sem uma análise extra considerável. 

Os logs de sistema e infraestrutura são produzidos por sistemas operacionais, dispositivos de rede, serviços de infraestrutura de nuvem e outros componentes de plataforma, em vez de código de aplicações. Eles capturam eventos (como erros do sistema operacional, problemas de rede e status da infraestrutura) para ajudar as equipes a conhecer a integridade e o desempenho do ambiente subjacente

Os logs de aplicações próprias vêm de serviços e aplicações internos, normalmente por meio de um SDK do OTel, biblioteca de registro, sidecar (um segundo contêiner de aplicativos executado ao lado do contêiner principal e usando os mesmos recursos) ou agente. Eles descrevem eventos de negócios, tratamento de solicitações, ações de usuários e erros internos. Eles podem ser enriquecidos com atributos de recursos e escopo de instrumentação (que descreve a origem do log dentro da entidade que o gerou) para fornecer uma visão mais completa do comportamento da aplicação.

Logs de terceiros são emitidos pelos serviços externos, componentes gerenciados e produtos SaaS dos quais muitos ambientes de TI empresariais dependem (APIs e bancos de dados externos, por exemplo). O OTel pode realizar a ingestão desses logs juntamente com os logs internos, para que as equipes de TI possam ver como as dependências externas afetam o ecossistema.

Os logs do OTLP são representados no modelo de dados de OTLP nativo e enviados por OTLP gRPC ou HTTP. Cada log é padronizado para neutralidade de fornecedor e correlação rápida com rastreamentos e métricas.

Os logs baseados em arquivos são gravados em arquivos (arquivos de log de aplicações ou logs de acesso de servidores da web), e os logs no estilo syslog são mensagens emitidas usando o protocolo syslog. O OTel normalmente coleta esses logs usando receptores que localizam arquivos ou escutam mensagens syslog e, em seguida, as converte em registros de logs do OTel para processamento unificado.

Logs HTTP e JSON são entregues por HTTP em JSON. O OpenTelemetry também é compatível com CSV, Common Log Format (CLF), LTSV e pares de valores-chave. Esses formatos são analisados pelo coletor no modelo comum de dados de log do OTel, para que possam ser consultados e correlacionados da mesma forma que os logs do OTLP nativos.

Imagine que os SREs vejam um aumento nos erros de "falha na finalização de compra" nos dashboards de observabilidade para um microsserviço de finalização de compra. Eles podem iniciar o processo de solução de problemas examinando os logs do OTel, que já estão padronizados e incluem atributos estruturados (como valor do pedido, contagem de itens e ID de rastreamento) para cada registro de log "pedido feito".

Os engenheiros podem verificar rapidamente se as falhas se correlacionam com altos volumes de pedidos, um método de envio específico ou uma região específica, apenas consultando os atributos de log. Eles também podem alinhar a janela de tempo entre logs, rastreamentos e métricas, pois o OTel usa carimbos de data/hora e metadados de recursos consistentes em todos os sinais de telemetria.

Os engenheiros confirmam que apenas os pedidos roteados para um provedor de pagamento específico estão falhando. Eles seguem um rastreamento de volta para todos os logs que compartilham esse atributo do provedor, onde encontram tempos de sessão excedidos repetidos. Com essas evidências, a equipe de TI pode encaminhar rapidamente o incidente ao proprietário certo e implementar uma estratégia de mitigação (passando para outro provedor, por exemplo).

O registro do OTel difere significativamente do registro tradicional em seus procedimentos de coleta, padronização, correlação e transmissão de logs.  

Os sistemas de registro tradicionais se concentram na agregação, indexação, pesquisa e alertas de logs com base em padrões de logs. São ferramentas poderosas para pesquisa de texto e análise histórica, mas geralmente examinam os logs isoladamente de outros dados de telemetria.

As abordagens de registro tradicionais consistem principalmente em gravar mensagens de texto localmente, para que os desenvolvedores possam depurar problemas em um único aplicativo ou host. Elas assumem que os usuários irão ler arquivos, filtrá-los e talvez enviá-los para um agregador de logs em um momento posterior. Elas também costumam usar formatos ad hoc, como linhas de texto simples, JSON vagamente estruturado ou padrões específicos de framework, sem um padrão de serviço cruzado.

E como cada equipe de desenvolvimento pode escolher seus próprios campos e nomenclaturas, a análise intersistemas é um processo complicado.

As ferramentas de registro tradicionais geralmente não incluem funcionalidades integradas de correlação ou migração; portanto, a correlação de dados e a integração com back-ends de observabilidade exigem processos manuais e etapas extras. As equipes de TI devem criar convenções personalizadas e regras de análise para unir eventos entre serviços, e a integração de dados de log na stack de observabilidade geralmente requer remetentes personalizados ou adaptadores de formato.

O registro do OpenTelemetry faz parte de um framework de observabilidade unificado que trata logs, métricas e rastreamentos como sinais interoperáveis de primeira classe, governados por convenções semânticas compartilhadas. Desde o início, ele projeta os logs para serem correlacionados e analisados em sistemas distribuídos, pois o objetivo é entender o comportamento do sistema de ponta a ponta.

Enquanto o registro tradicional é específico da stack e do back-end, o registro do OTel é deliberadamente agnóstico. Ele fornece pontes e appenders para que os frameworks de registro existentes possam emitir dados no formato OTel sem precisar reescrever cada chamada de log.

Esse escopo e abordagem unificados permite que as equipes de TI criem fluxos de trabalho holísticos de solução de problemas, nos quais podem migrar sem dificuldades entre dashboards e tipos de dados para entender falhas complexas e distribuídas.

O registro do OTel fornece logs padronizados e repletos de contexto que se integram totalmente a rastreamentos e métricas, tornando a solução de problemas e a análise muito mais eficazes do que as abordagens tradicionais. Os benefícios incluem: