No passado, quando falávamos sobre back-end, geralmente nos referíamos a um grande aplicativo com um único grande banco de dados, e o registro em log era suficiente para monitoramento. Agora, graças a tecnologias como   ,   se tornaram o padrão. Os aplicativos são mais numerosos e distribuídos, e o registro tradicional não é mais suficiente para   e diagnosticar problemas em nossos aplicativos. o Kubernetes os microsserviços depurar  Uma excelente solução para organizar o monitoramento é o OpenTelemetry — um kit de ferramentas moderno que pode ser usado para depuração e análise de desempenho de sistemas distribuídos.  Este artigo é destinado a profissionais de TI que buscam ampliar seus conhecimentos em otimização de backend. A seguir detalharemos o que é OpenTelemetry, seus principais conceitos e os problemas que ajuda a resolver. Se você estiver interessado em saber como o OpenTelemetry pode mudar sua abordagem de monitoramento e depuração de sistemas backend, aumentando sua confiabilidade e eficiência — continue lendo.  Uma breve história do OpenTelemetry  As grandes empresas de tecnologia enfrentaram pela primeira vez o desafio do registo e rastreio distribuído no final dos anos 2000. Em 2010, o Google publicou um artigo,  , que lançou as bases para a ferramenta de rastreamento do Twitter, Zipkin, lançada em 2012.   Dapper, uma infraestrutura de rastreamento de sistemas distribuídos em larga escala  Em 2014, surgiu o Kubernetes, simplificando significativamente o desenvolvimento de microsserviços e outros sistemas distribuídos em nuvem. Isso fez com que muitas empresas encontrassem problemas com registro e rastreamento distribuídos em microsserviços. Para padronizar o rastreamento distribuído, foi criado o padrão OpenTracing, adotado pela CNCF, e o projeto OpenCensus do Google.  Em 2019, os projetos OpenTracing e OpenCensus anunciaram uma fusão sob o nome OpenTelemetry. Esta plataforma combina as melhores práticas acumuladas ao longo de muitos anos, permitindo a integração perfeita de rastreamento, registro e métricas em qualquer sistema, independentemente da sua complexidade.  Hoje, o OpenTelemetry não é apenas um projeto; é um padrão da indústria para coleta e transmissão de dados de telemetria. É desenvolvido e apoiado por uma comunidade de especialistas e empresas líderes de mercado como Google e Microsoft. O projeto continua evoluindo, ganhando novas capacidades para simplificar o processo de integração e utilização.    O que há dentro?  OpenTelemetry é um conjunto abrangente de práticas e ferramentas que definem quais sinais um aplicativo pode gerar para interagir com o mundo exterior e como esses sinais podem ser coletados e visualizados para monitorar o estado dos aplicativos e do sistema como um todo. Os três principais tipos de sinais são   e   . rastreamento, registro coleta de métricas  **Vamos dar uma olhada em cada componente: \   Contextos  OpenTelemetry introduz o conceito de contextos de operação. Um contexto inclui principalmente atributos como   (identificador para a operação atual) e   (identificador para uma subsolicitação, com cada nova tentativa de uma subsolicitação tendo um   exclusivo). `trace_id` `span_id` `span_id`  Além disso, um contexto pode conter informações estáticas, como o nome do nó onde o aplicativo está implementado ou o nome do ambiente (prod/qa). Esses campos, conhecidos como recursos na terminologia OpenTelemetry, são anexados a cada log, métrica ou rastreamento para facilitar a pesquisa. Os contextos também podem incluir dados dinâmicos, como o identificador do endpoint atual (   ), que pode ser anexado seletivamente a grupos de logs, métricas ou rastreamentos. `http_path: "GET /user/:id/info"`  Os contextos OpenTelemetry podem ser transmitidos entre diferentes aplicativos usando protocolos de propagação de contexto. Esses protocolos consistem em conjuntos de cabeçalhos que são adicionados a cada solicitação HTTP ou gRPC ou aos cabeçalhos de mensagens para filas. Isso permite que aplicativos downstream reconstruam o contexto de operação a partir desses cabeçalhos.   Aqui estão alguns exemplos de propagação de contexto:    Este é um conjunto de cabeçalhos (   ) originalmente desenvolvido para o sistema de rastreamento Zipkin. Foi adaptado para OpenTracing e usado por muitas ferramentas e bibliotecas. B3-Propagation carrega   /   e um sinalizador indicando se a amostragem é necessária. B3-Propagation x-b3-* trace_id span_id    Desenvolvido pelo grupo de trabalho do W3C, este padrão unifica várias abordagens de propagação de contexto em um único padrão e é o padrão no OpenTelemetry. Um bom exemplo de aplicação desses padrões é rastrear a execução de uma solicitação que passa por microsserviços implementados com diferentes tecnologias sem comprometer a precisão do monitoramento e da depuração. Contexto de rastreamento do W3C   Rastreamento     Rastreamento é o processo de registrar e posteriormente visualizar a linha do tempo do caminho de uma solicitação por meio de vários microsserviços.  Na visualização, cada barra é chamada de "span" e possui um   exclusivo. O intervalo raiz é conhecido como   e possui um   , que serve como identificador para toda a solicitação. "span_id" "trace" "trace_id"   Este tipo de visualização permite:  Analise o tempo de execução de solicitações em diferentes sistemas e bancos de dados para identificar gargalos que precisam de otimização.  Detecte dependências cíclicas entre serviços.  Encontre solicitações duplicadas. Usando dados de rastreamento, você também pode criar análises adicionais, como criar um mapa de microsserviços ou distribuir o tempo entre diferentes sistemas durante o processamento da operação. Mesmo que você não use dados de rastreamento para visualizar linhas do tempo, o OpenTelemetry ainda gera   e   para uso em outros sinais. trace_id span_id   Histórico  Apesar de sua aparente simplicidade, o registro continua sendo uma das ferramentas mais poderosas para diagnosticar problemas. OpenTelemetry aprimora o registro tradicional adicionando informações contextuais. Especificamente, se um rastreamento ativo estiver presente, os atributos `trace_id` e `span_id` serão adicionados automaticamente aos logs, vinculando-os à linha do tempo do rastreamento. Além disso, os atributos de log podem incluir informações estáticas do contexto OpenTelemetry, como o identificador do nó, bem como informações dinâmicas, como o identificador do endpoint HTTP atual (`http_path: "GET /user/:id"`).  Usando o `trace_id`, você pode encontrar logs de todos os microsserviços associados à solicitação atual, enquanto o `span_id` permite diferenciar entre subsolicitações. Por exemplo, no caso de novas tentativas, os logs de tentativas diferentes terão `span_id`s diferentes. O uso desses identificadores permite uma análise rápida de todo o comportamento do sistema em tempo real, acelerando o diagnóstico de problemas e melhorando a estabilidade e a confiabilidade.   Métricas  A coleta de métricas fornece dados quantitativos sobre o desempenho do sistema, como latência, taxas de erro, uso de recursos e muito mais. O monitoramento de métricas em tempo real permite responder prontamente às mudanças de desempenho, evitar falhas e esgotamento de recursos e garantir alta disponibilidade e confiabilidade do aplicativo para os usuários.  A integração com sistemas de armazenamento e visualização de métricas como Prometheus e Grafana facilita a visualização desses dados, simplificando significativamente o monitoramento.   Coletores de métricas  Os coletores de métricas OpenTelemetry são compatíveis com os padrões Prometheus e OpenMetrics, permitindo uma transição fácil para soluções OpenTelemetry sem alterações significativas. O OpenTelemetry SDK permite que exemplos de trace_id sejam exportados junto com métricas, possibilitando correlacionar métricas com exemplos de log e rastreamentos.  Correlação de Sinal   Juntos, logs, métricas e rastreamento criam uma visão abrangente do estado do sistema:  Os logs fornecem informações sobre eventos do sistema, permitindo rápida identificação e resolução de erros.  As métricas refletem indicadores de desempenho qualitativos e quantitativos do sistema, como tempos de resposta ou taxas de erro.  O rastreamento complementa essa visão mostrando o caminho de execução da solicitação através de vários componentes do sistema, ajudando a compreender suas inter-relações. A correlação clara entre logs, rastreamentos e métricas é um recurso distintivo do OpenTelemetry. Por exemplo, o Grafana permite que os usuários vejam as métricas correspondentes de rastreamento e solicitação ao visualizar um log, melhorando muito a usabilidade e a eficiência da plataforma.   Além dos três componentes principais, o OpenTelemetry inclui os conceitos de Amostragem, Bagagem e gerenciamento de contexto de operação.   Amostragem  Em sistemas de alta carga, o volume de logs e rastreamentos torna-se enorme, exigindo recursos substanciais para infraestrutura e armazenamento de dados. Para resolver esse problema, os padrões OpenTelemetry incluem amostragem de sinal — a capacidade de exportar apenas uma parte dos rastreamentos e logs. Por exemplo, você pode exportar sinais detalhados de uma porcentagem de solicitações, solicitações de longa duração ou solicitações de erro. Esta abordagem permite uma amostragem suficiente para construir estatísticas, poupando ao mesmo tempo recursos significativos.  No entanto, se cada sistema decidir independentemente quais solicitações monitorar detalhadamente, acabaremos com uma visão fragmentada de cada solicitação. Alguns sistemas podem exportar dados detalhados, enquanto outros podem exportar apenas parcialmente ou nem exportar.  Para resolver este problema, os mecanismos de propagação de contexto do OpenTelemetry transmitem um sinalizador de amostragem junto com `trace_id`/`span_id`. Isto garante que se o serviço inicial que recebe a solicitação do usuário decidir que a solicitação deve ser monitorada detalhadamente, todos os outros sistemas farão o mesmo. Caso contrário, todos os sistemas deverão exportar parcialmente ou não sinais para conservar recursos. Essa abordagem é chamada de "Amostragem de Cabeça" — uma decisão tomada no início do processamento da solicitação, de forma aleatória ou baseada em alguns atributos de entrada.  Além disso, o OpenTelemetry suporta "Tail Sampling", onde todos os aplicativos sempre exportam todos os sinais em detalhes, mas existe um buffer intermediário. Depois de coletar todos os dados, esse buffer decide se retém os dados completos ou apenas uma amostra parcial. Este método permite uma amostra mais representativa de cada categoria de solicitação (bem-sucedida/longa/erro), mas requer configuração de infraestrutura adicional.   Bagagem  O mecanismo Baggage permite que pares arbitrários de valores-chave sejam transmitidos junto com   /   , passando automaticamente entre todos os microsserviços durante o processamento da solicitação. Isso é útil para transmitir informações adicionais necessárias ao longo do caminho da solicitação, como informações do usuário ou configurações do ambiente de tempo de execução. trace_id span_id     Exemplo de cabeçalho para transmissão de bagagem de acordo com o padrão W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5   Aqui estão alguns exemplos de uso de bagagem:    como   ,   ou   podem ser passadas por todos os microsserviços. Os aplicativos podem registrar automaticamente essas informações, permitindo pesquisas de log por contexto de usuário para a solicitação original. Passando informações de contexto de negócios userId productId deviceId  Configurações   para SDKs ou infraestrutura. específicas de parâmetros de configuração    Sinalizadores que ajudam os balanceadores de carga a tomar decisões de roteamento. Durante o teste, algumas solicitações podem precisar ser roteadas para back-ends simulados. Como a bagagem é transmitida automaticamente por todos os serviços, não há necessidade de criar protocolos adicionais – basta configurar uma regra no balanceador de carga. Sinalizadores de roteamento  Observe que, embora o impacto da Bagagem no desempenho seja mínimo, o uso excessivo pode aumentar significativamente a carga da rede e do serviço. Escolha cuidadosamente quais dados você realmente precisa passar pela Bagagem para evitar problemas de desempenho.   Implementação de Infraestrutura  A implementação do OpenTelemetry no nível da infraestrutura envolve a integração de backends do OpenTelemetry na arquitetura do aplicativo e a configuração da infraestrutura para agregação de dados.   O processo consiste em quatro etapas:    No primeiro estágio, os SDKs OpenTelemetry são integrados diretamente aos aplicativos para coletar métricas, logs e rastreamentos, garantindo um fluxo contínuo de dados sobre o desempenho de cada componente do sistema. Integração de aplicativos    Os dados coletados são roteados de aplicativos através de exportadores para sistemas externos para processamento adicional, como sistemas de registro, monitoramento, rastreio ou análise, dependendo de suas necessidades. Configurando Exportadores    Este estágio pode envolver a normalização de dados, seu enriquecimento com informações adicionais e a fusão de dados de diferentes fontes para criar uma visão unificada do estado do sistema. Agregação e armazenamento    Por fim, os dados processados são apresentados como painéis em sistemas como Grafana (para métricas e rastreamentos) ou Kibana (para logs). Isso permite que as equipes avaliem rapidamente a integridade do sistema, identifiquem problemas e tendências e configurem alertas com base nos sinais gerados. Visualização de dados  Implementação de Aplicativo  Para integrar com um aplicativo, você precisa conectar o OpenTelemetry SDK apropriado para a linguagem de programação em uso ou empregar bibliotecas e estruturas que suportem diretamente o OpenTelemetry. OpenTelemetry frequentemente implementa interfaces amplamente utilizadas de bibliotecas conhecidas, permitindo substituições imediatas. Por exemplo, a biblioteca Micrometer é comumente usada para coleta de métricas no ecossistema Java. O OpenTelemetry SDK fornece implementações de interfaces Micrometer, permitindo a exportação de métricas sem alterar o código principal do aplicativo. Além disso, o OpenTelemetry oferece implementações de interfaces OpenTracing e OpenCensus mais antigas, facilitando uma migração tranquila para o OpenTelemetry.  Conclusão  Nos sistemas de TI, o OpenTelemetry pode se tornar a chave para o futuro de back-ends confiáveis e eficientes. Essa ferramenta simplifica a depuração e o monitoramento e também abre oportunidades para uma compreensão profunda do desempenho e da otimização do aplicativo em um novo nível. Junte-se à comunidade OpenTelemetry para ajudar a moldar um futuro onde o desenvolvimento de back-end será mais simples e eficaz!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Make resilience your competitive advantage

O que é OpenTelemetry e como ele pode melhorar a qualidade do back-end?

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps