Métricas na Observabilidade: tipos, séries temporais e OpenTelemetry

Se os logs são a biografia detalhada de um evento e os traces são o mapa da jornada de uma requisição, as métricas são os sinais vitais do sistema em tempo real. São o pilar mais eficiente da observabilidade: pequenas em tamanho, ricas em informação quando analisadas ao longo do tempo.

Em ambientes de produção modernos, métricas são a primeira camada de detecção de problemas. Um spike de latência, uma queda de throughput ou um aumento de taxa de erro — todos aparecem nas métricas antes que qualquer usuário abra um ticket de suporte. A velocidade e a granularidade com que métricas são coletadas determinam diretamente o MTTD de um time.

Este guia técnico explica o que são métricas no contexto da observabilidade, os principais tipos, como séries temporais funcionam e como o padrão OpenTelemetry padroniza a coleta.

O que são métricas na observabilidade?

Métricas são medidas numéricas do comportamento e estado de um sistema, coletadas ao longo do tempo. Cada ponto de dado é um par (timestamp, valor) associado a um conjunto de labels que descrevem o contexto da medição — qual serviço, qual instância, qual endpoint.

Diferentemente dos logs — que capturam eventos discretos com texto completo — métricas são otimizadas para armazenamento e análise matemática. Uma métrica de latência não armazena o detalhe de cada requisição: armazena a distribuição estatística (p95, p99) sobre janelas de tempo configuráveis.

Tipos de métricas

Counter (Contador)

Um valor que só cresce, nunca diminui. Exemplos: número total de requisições recebidas, total de erros, total de bytes transmitidos. Counters são analisados pela taxa de mudança — “quantas requisições por segundo?” — não pelo valor absoluto.

Em Prometheus, counters terminam convencionalmente com _total: http_requests_total, errors_total. O operador rate() converte o counter em uma taxa por segundo sobre uma janela de tempo.

Gauge (Medidor)

Um valor que pode subir e descer livremente. Exemplos: uso atual de CPU, memória disponível, número de conexões abertas. Gauges representam o estado atual de um recurso em um momento específico.

Gauges são a métrica mais intuitiva e também a mais propensa a gerar fadiga de alertas quando configurados com thresholds estáticos — um CPU de 90% durante um job agendado é normal; o mesmo valor fora desse horário é uma anomalia.

Histogram

Distribui os valores observados em buckets predefinidos. É a métrica ideal para latência: em vez de armazenar o tempo de cada requisição, o histogram conta quantas ficaram abaixo de cada threshold — 0.05s, 0.1s, 0.5s, 1s, etc.

Histogramas permitem calcular percentis como p95 e p99 — as métricas de latência mais relevantes para SLOs, pois capturam a experiência dos usuários mais lentos em vez de esconder problemas atrás da média.

Summary

Similar ao histogram, mas calcula os quantis no cliente em vez de no servidor de métricas. Tem menor overhead no servidor mas não permite agregar quantis de múltiplas instâncias — limitação importante em ambientes com múltiplas réplicas do mesmo serviço.

Séries temporais e labels

Métricas são armazenadas como séries temporais: sequências de pontos (timestamp, valor) associadas a um conjunto de labels. É a combinação do nome da métrica com seus labels que define uma série temporal única.

Por exemplo, http_requests_total com os labels method="GET" e status="200" é uma série diferente de http_requests_total com method="POST" e status="500".

A cardinalidade de labels — o número de combinações únicas possíveis — é o principal fator de performance em sistemas de métricas. Labels de alta cardinalidade como user_id ou request_id podem criar milhões de séries temporais e sobrecarregar o storage. O padrão é usar labels de baixa cardinalidade: método HTTP, código de status, nome do serviço, região.

Os 4 Sinais de Ouro e os métodos USE e RED

O SRE do Google definiu os 4 Sinais de Ouro como o conjunto mínimo de métricas que todo serviço deve monitorar: latência (tempo de resposta), tráfego (volume de requisições), erros (taxa de falhas) e saturação (quão próximo do limite o sistema está).

Para infraestrutura, o método USE — Utilization, Saturation, Errors — fornece um framework equivalente. Para serviços orientados a requisições, o método RED — Rate, Errors, Duration — é a versão simplificada dos 4 Sinais de Ouro, amplamente adotada em arquiteturas de microsserviços.

OpenTelemetry e a padronização de métricas

O padrão OpenTelemetry define uma API e SDK para coleta de métricas agnóstica ao backend. Instrumentar com OpenTelemetry Metrics significa que os dados podem ser exportados para Prometheus, Datadog, Grafana Mimir ou qualquer outro backend sem alterar o código de instrumentação.

O OpenTelemetry também define convenções semânticas para métricas — nomes e labels padronizados para tipos comuns de serviços (HTTP, banco de dados, mensageria). Essa padronização garante que métricas de diferentes serviços sigam o mesmo vocabulário, viabilizando dashboards e alertas reutilizáveis em toda a organização.

Conclusão

Métricas são o pilar de velocidade da observabilidade — o tipo de dado mais eficiente para detectar anomalias em tempo real e alimentar alertas de alta qualidade. A combinação de counters, gauges e histogramas cobre as necessidades de monitoramento de qualquer serviço, desde latência de APIs até uso de recursos de infraestrutura.

A chave para métricas eficazes é a disciplina de labels: baixa cardinalidade, campos consistentes e alinhamento com as convenções semânticas do OpenTelemetry. Com essas bases, métricas se tornam correlacionáveis com logs e traces, completando o tripé de observabilidade. Para estruturar sua estratégia de métricas e observabilidade, fale com nossos especialistas.