O que são métricas OpenTelemetry?

Assim como os logs e rastreamentos do OpenTelemetry, as métrica OTel fornecem sinais de telemetria padronizados que utilizam um modelo de dados e um protocolo de transmissão comuns e independentes de linguagem – o OpenTelemetry Protocol (OTLP), para ser mais preciso – para ingestão de dados de diferentes fontes, sistemas e formatos e enviá-los para backends de observabilidade.

Métricas OTel dependem da instrumentação OpenTelemetry para coletar dados de séries temporais – como uso de CPU e memória, throughput, taxas de erro, contagem de requisições e tempos de resposta – de aplicações e componentes de infraestrutura enquanto eles rodam. Após os desenvolvedores instrumentarem o código para registrar as métricas necessárias, o OTel permite que essas métricas sejam agregadas e exportadas para qualquer ferramenta de observabilidade de backend para armazenamento, consulta e visualização, tudo sem alterar a instrumentação.

As métricas normalmente são os primeiros sinais de telemetria a revelar um problema do sistema. No framework OTel, eles são integrados com logs (registros imutáveis de eventos discretos do sistema) e rastreamentos (a jornada de ponta a ponta de uma requisição de dados) que dependem dos mesmos conceitos e metadados.

Essa dinâmica permite que desenvolvedores e engenheiros de confiabilidade de sites (SREs) usem métricas como um sistema de alerta precoce de alto nível. Eles podem acompanhar todo o percurso de uma falha (incluindo as métricas de cada serviço com o qual o componente com falha interagiu) em uma única visão integrada e, de forma rápida, acessar rastreamentos e logs para realizar a análise da causa raiz.

Na prática, isso significa que as equipes de TI podem passar de "este endpoint está lento" para "estas solicitações e dependências específicas são o problema", com apenas alguns cliques.

Além disso, os protocolos de padronização do OTel facilitam a correlação automatizada de sinais entre fornecedores de observabilidade, dando às empresas a flexibilidade de mudar de ferramentas de observabilidade sempre que preferirem, ou usarem várias ferramentas simultaneamente.

As métricas são um componente fundamental do OpenTelemetry. O OpenTelemetry é uma 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 fornecedor e outras ferramentas para instrumentação de aplicações, sistemas e dispositivos.

O código de instrumentação utilizado variava bastante, e nenhum fornecedor comercial oferecia uma ferramenta capaz de coletar dados de todos os aplicativos e serviços em uma rede. Essa lacuna de funcionalidade dificultava (e muitas vezes impossibilitava) que as equipes coletassem 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.

Digamos que uma equipe de desenvolvimento queira trocar as ferramentas de backend. Eles teriam que reestruturar completamente seu código e configurar novos agentes (componentes de software que executam tarefas automatizadas de compilação e implementação) para enviar dados de telemetria aos novos servidores. As abordagens fragmentadas criariam 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 backend. 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.

As métricas do OpenTelemetry dependem de um grupo de componentes relacionados que, juntos, definem como as métricas são produzidas, descritas e enviadas aos backends de observabilidade. Elas incluem:

Os instrumentos são as ferramentas que o código usa para registrar valores de métricas. Eles registram valores de duas maneiras: de forma síncrona (diretamente no caminho de execução, à medida que o código é executado) e de forma assíncrona (sempre que o SDK solicita valores do código).

Por serem executados em conjunto com as operações, os instrumentos síncronos podem capturar o contexto de rastreamento atual e os atributos do evento, facilitando a correlação das métricas coletadas com logs e rastreamentos.

Os instrumentos assíncronos são atualizados por funções de retorno de chamada baseadas em pull que o SDK chama em um intervalo de coleta predeterminado. Esses instrumentos são úteis para registrar valores que são amostrados periodicamente, em vez de a cada solicitação do usuário (uso da CPU ou memória, por exemplo).

A instrumentação OTel fica entre a lógica da aplicação e o pipeline de métricas, transformando eventos, como "solicitação HTTP concluída", em medições estruturadas que o SDK pode agregar e exportar. Cada tipo de instrumento métrico é otimizado para um padrão de medição específico e tem uma estratégia de agregação associada, que descreve como o SDK deve combinar medições individuais em métricas exportadas.

Os tipos de instrumentos mais comuns são:

• Os contadores são instrumentos síncronos que registram incrementos que aumentam ao longo do tempo (como o número total de solicitações ou o total de bytes enviados desde o início do processo). Os contadores também são monotônicos; portanto, cada vez que registram uma nova medição, eles a adicionam ao valor existente, em vez de substituí-lo.

• Os contadores UpDown são instrumentos síncronos que registram valores que podem aumentar ou diminuir ao longo do tempo (número de usuários ativos ou tamanho da fila, por exemplo). Ao contrário dos contadores padrão, os contadores UpDown não são monotônicos, portanto, ajustam os totais para cima ou para baixo substituindo os valores existentes.

• Os contadores assíncronos e os contadores assíncronos UpDown são semelhantes às suas contrapartes síncronas, mas registram os valores uma única vez por exportação, em vez de coletá-los durante a execução do código.

• Os medidores são instrumentos síncronos que registram valores que podem aumentar ou diminuir arbitrariamente a cada atualização de dados, representando os valores no momento em que são coletados pelo código. Além dos medidores síncronos, a coleta de métricas exige medidores observáveis, que são instrumentos assíncronos que extraem valores atuais sempre que o backend de métricas coleta dados.
  
  Os medidores registram instantâneos de valores da mesma forma que as câmeras capturam instantâneos de seus objetos fotografados. E como os medidores não são cumulativos, eles normalmente são aplicados a valores não aditivos em que a soma não faria sentido (uso de memória ou temperatura, por exemplo).

• Os histogramas são instrumentos síncronos que capturam quantas medições se enquadram em diferentes faixas de valores, em vez de rastrear um único número (como um valor total ou atual). Eles agrupam valores em "intervalos", permitindo que as equipes de TI calculem percentis e compreendam a distribuição de valores para métricas como duração da solicitação, latência e tamanho da carga útil.

O OTel define um modelo de dados de métricas padronizado e séries temporais que transformam eventos métricos individuais em séries numéricas claras, consultáveis e baseadas no tempo, que as equipes de TI podem armazenar e analisar em plataformas de observabilidade.

O OpenTelemetry descreve métricas usando três modelos relacionados: o modelo de evento (medições brutas de instrumentos), o modelo de fluxo OTLP (como essas medições são agrupadas e enviadas) e o modelo de série temporal (como os backends as armazenam).

Na prática, o código de aplicações registra eventos usando o modelo de eventos, o SDK/Collector transforma-os em fluxos OTLP e a plataforma de backend os armazena como séries temporais, como "solicitações por segundo para o serviço X com status 200" ao longo do tempo.

As convenções semânticas (também chamadas de convenções de nomenclatura) definem nomes, unidades e chaves de atributos padronizados para métricas comuns, de modo que diferentes serviços e bibliotecas produzam telemetria consistente. Por exemplo, as convenções prescrevem nomes como “http.server.duration” para latência de solicitação do servidor HTTP e recomendam unidades como segundos ou milissegundos para medir a duração.

O uso das convenções semânticas do OTel permite que as equipes conectem métricas a dashboards pré-criados e sistemas de alerta que esperam um esquema específico, o que reduz o tempo gasto com trabalho de configuração personalizada. Isso também facilita a colaboração entre equipes, porque todos falam a mesma “linguagem métrica” em todos os microsserviços.

Além disso, as funcionalidades de propagação de contexto podem vincular métricas com rastreios relacionados (usando exemplares) e logs, transportando contexto compartilhado, como identificadores de rastreio ou span, entre os limites dos serviços.

Por exemplo, um propagador OTel pode extrair o contexto de entrada de um manipulador de solicitações, iniciar um intervalo de rastreamento com ele e usar o mesmo contexto para registrar métricas de latência e escrever entradas de log. Dessa forma, tanto o ponto de métrica quanto a entrada de log são marcados com o rastreamento atual.

Quando o código do aplicativo faz uma chamada downstream, o propagador injeta o mesmo contexto na solicitação de saída. O código extrai esse contexto, inicia seu próprio span filho e o utiliza em suas próprias métricas e logs, mantendo todas as informações de ambos os serviços vinculadas ao mesmo rastreamento de ponta a ponta.

Os atributos (também conhecidos como rótulos, tags ou dimensões) são pares de valores-chave anexados a medições individuais ou pontos de dados agregados. Eles definem total ou parcialmente uma série temporal junto com o nome da métrica, o tipo de agregação e a unidade. Sem atributos, todas as medições de uma métrica se reduziriam a uma única série sem diferenciação.

A adição de atributos (como nome do serviço, endpoint, código de status HTTP, região ou ID do tenant) transforma métricas simples em fluxos de métricas dimensionais e especializadas que as equipes podem segmentar e analisar em ferramentas de observabilidade. As equipes podem obter visualizações em alta resolução filtradas ou agrupadas por qualquer dimensão que escolherem.

Um bom projeto de atributos também equilibra os detalhes com a cardinalidade métrica (o número de valores únicos que um atributo pode assumir), para que as equipes possam evitar a explosão de rótulos enquanto ainda executam consultas úteis.

Uma medição é uma leitura única em nível de evento feita por um instrumento em um momento específico e, muitas vezes, acompanhada por atributos. Por exemplo, quando uma requisição HTTP termina, você pode registrar uma latência de 120 milissegundos com atributos como route="/login" e status_code=200 representando o código de rota e status.

Cada registro individual é uma medição separada que descreve o que aconteceu durante aquela operação.

As medições são armazenadas brevemente dentro do SDK, que então converte as medições brutas em pontos de dados dentro de fluxos métricos maiores. Em vez de mostrar todas as solicitações, um ponto de dados agregado pode mostrar que “para a rota/login com status 200, entre 10:00:00 e 10:00:10, houve 500 solicitações com uma duração total de 25 segundos”. São esses pontos de dados que são eventualmente exportados e armazenados nos backends de observabilidade.

A API de métricas do OpenTelemetry é o conjunto de interfaces que o código da aplicação chama para produzir métricas. Ele foi projetado para ser independente de fornecedor, dissociando a instrumentação da implementação concreta do SDK. As equipes de TI podem escrever a instrumentação uma vez (usando a API padrão) e, em seguida, trocar SDKs, exportadores e backends sem executar etapas extras.

Três interfaces principais formam a estrutura da API de métricas do OTel: Meter Providers, Meters e instrumentos de métrica.

Meter Providers são o ponto de entrada da API e são responsáveis pela criação de instâncias de medidores. Eles determinam quais leitores e exportadores de métricas usar, quais visualizações e agregações aplicar e com que frequência coletar e exportar dados. O Meter Provider normalmente carrega uma vez durante a inicialização da aplicação (geralmente como um provedor global), de modo que todos os medidores e instrumentos compartilhem definições de recursos consistentes e pipelines de exportação.

Os Meters são os objetos que o código da aplicação usa para criar contadores, histogramas e indicadores. Cada Meter normalmente recebe o nome de uma biblioteca ou serviço (por exemplo, "bank.payment"), para que as métricas provenientes desse código possam ser agrupadas e identificadas de forma consistente.

Os Meters não armazenam dados em si; em vez disso, servem como fábricas para instrumentos e transmitem medições registradas para o SDK subjacente para agregação e exportação. Como os Meters são obtidos de um Meter Provider, eles sempre operam com a configuração, as visualizações e os Exporters definidos pelo Provider.

Em seguida, os instrumentos fornecem instruções para que o código possa relatar medições com atributos.

O SDK do OpenTelemetry é uma implementação concreta da API do OpenTelemetry que transforma as chamadas de API em pontos de dados de telemetria reais. Ele fornece uma biblioteca específica de linguagem (como Java™ ou Python) que coleta, agrega e prepara dados de métricas para exportação.

Os SDKs gerenciam ciclos de vida de instrumentação, lidam com armazenamento na memória para medições, executam retornos de chamadas para instrumentos assíncronos, aplicam agregações e visualizações configuradas e controlam intervalos de coleta de métricas (normalmente de 10 a 60 segundos).

Dentro do SDK, os processadores aplicam agregação e lógica adicional, incluindo filtragem, limitação de taxa ou transformação de fluxos de métricas, antes de enviá-los adiante.

Os Exporters convertem pontos de dados de métricas processadas em formatos específicos de backend e os enviam para backends externos ou plataformas de observabilidade usando protocolos compatíveis (como OTLP).

As equipes podem optar por encadear vários Exporters no SDK para suporte a vários backends em ambientes que exigem alta disponibilidade e redundância. Nessas instâncias, os Collectors do OpenTelemetry atuam como proxies inteligentes que podem enviar métricas para vários backends simultaneamente, fazer tentativas de exportação ou autenticar dados em escala. 

As agregações definem como as medições individuais brutas são matematicamente combinadas em estatísticas resumidas que os backends armazenam e consultam como pontos de dados de séries temporais. Os dados brutos são acumulados pelo agregador do SDK em um único ponto de dados por intervalo de coleta para cada série temporal exclusiva.

Os padrões comuns de agregação incluem:

• Soma, que adiciona todos os valores para quantidades cumulativas (como bytes transferidos).

• LastValue, que mantém apenas a medição mais recente, descartando as anteriores.

• Agregação de histograma, que agrupa valores em intervalos para que as equipes possam calcular percentis e detectar valores discrepantes.

• Drop, que descarta todos os valores para proteção contra dados de alta cardinalidade (dados com um grande número de valores únicos).

As agregações também carregam metadados de temporalidade, que informam aos backends como interpretar um valor de métrica ao longo do tempo. Os dois principais tipos são:

• Os valores cumulativos refletem o total desde o início do processo. Esses valores são redefinidos somente quando o processo é reiniciado, e os backends calculam as taxas diferenciando os pontos de dados.

• Os valores delta refletem as mudanças ocorridas desde a última coleta de dados. Os backends podem somar deltas diretamente para determinar as taxas.

Os SDKs aplicam automaticamente a agregação correta com base no tipo de instrumento. Eles também permitem que as equipes de TI mudem de totais simples para histogramas detalhados ou outros algoritmos, deixando a instrumentação inalterada.

As métricas mostram tendências e enviam alertas, os rastreamentos revelam o caminho das solicitações e os logs fornecem um contexto rico em nível de evento. Correlacionar métricas com rastreabilidade e logs conecta os três principais sinais de observabilidade (conhecidos como os “pilares da observabilidade”) para que as equipes possam obter uma visão em camadas do comportamento do sistema.

A métrica pode, por exemplo, mostrar tendências agregadas como "a taxa de erros aumentou às 14h15", mas não consegue revelar quais solicitações falharam ou por quê. Os rastreamentos esclarecem os caminhos problemáticos de solicitações individuais em todos os serviços, mas sem métricas, eles não podem ajudar as equipes a determinar se uma solicitação ruim é um valor discrepante ou um problema sistêmico. Os logs fornecem mensagens de erro e eventos detalhados, mas sem contexto, eles são apenas ruído.

A correlação dos três sinais permite que as equipes de TI migrem sem dificuldades de tendências métricas de alto nível para o rastreamento afetado e os logs relacionados em segundos.

As métricas OTel diferem fundamentalmente das métricas tradicionais. As métricas tradicionais normalmente se referem a abordagens de monitoramento legadas que se concentram em contadores simples e predefinidos para o uso de recursos. Essas métricas enfatizam medições em nível de host ou específicas da aplicação. 

As métricas do OpenTelemetry, por outro lado, fazem parte de um framework de observabilidade unificado e independente de fornecedor que padroniza a coleta entre rastreamentos, logs e métricas para ambientes de TI distribuídos. Eles se baseiam em métricas tradicionais, fornecendo um modelo de dados e instrumentação mais flexíveis, incluindo UpDownCounters para mudanças bidirecionais e histogramas que suportam intervalos exponenciais. Eles também fornecem atributos explícitos, unidades e registros de data e hora para enriquecer as métricas.

As métricas de OTel também são diferentes das métricas tradicionais em termos de design, métodos de coleta e aplicabilidade a sistemas modernos.

As métricas tradicionais apresentam um modelo rígido e full-stack que acopla firmemente a coleta, o armazenamento e a consulta, muitas vezes usando valores apenas cumulativos de contadores básicos, medidores, resumos e histogramas com intervalos explícitos (que exigem agrupamento manual).

As métricas do OpenTelemetry empregam um design modular de três camadas (com uma API, um SDK e um protocolo) que separa a geração de sinais do processamento e da exportação. Essa configuração permite que as métricas de OTel ofereçam suporte a funcionalidades avançadas, como temporalidade delta, valores inteiros, metadados mínimos e máximos em histogramas e histogramas exponenciais para escalabilidade dinâmica.

As abordagens tradicionais dependem da coleta de dados baseada em pull a partir de endpoints de API expostos, principalmente para métricas analisadas de forma isolada. Elas usam instrumentação manual e oferecem suporte limitado para rastreamentos ou logs, o que leva a pipelines fragmentados de telemetria e observabilidade.

O OpenTelemetry utiliza OTLP (um protocolo binário) para coleta de dados baseada em push, permitindo a coleta unificada de rastreamentos, métricas e logs por meio de instrumentação automática e manual. O OTel também fornece um Collector para facilitar a transformação de dados, o armazenamento em lote e o roteamento para ferramentas de backend, o que ajuda as equipes de TI a lidar com as preocupações de armazenamento de aplicações.

Os dados de telemetria tradicionais funcionam bem para configurações simples e monolíticas. No entanto, eles falham em ambientes de microsserviços devido a recursos insuficientes, problemas de lock-in com fornecedor e sinais isolados que obscurecem as dependências e não detectam falhas em cascata.

O OpenTelemetry se destaca em ambientes distribuídos nativos da nuvem, pois oferece telemetria correlacionada e independente do fornecedor para visibilidade de ponta a ponta dos fluxos de requisições entre serviços, gargalos de latência e diagnósticos de recursos. O Otel também oferece suporte à amostragem e à integração de ferramentas híbridas, o que ajuda a telemetria e a instrumentação a escalarem junto com o ambiente de TI. 

As métricas do OpenTelemetry fornecem medidas quantitativas padronizadas que ajudam a melhorar a observabilidade em arquiteturas modernas. Elas oferecem insights detalhados sobre o desempenho do sistema, permitindo que desenvolvedores e engenheiros implementem estratégias proativas de resolução de problemas e otimização.

Outros benefícios são: