O que são Métricas? Definição, Tipos e Como Usar em Observabilidade

Uma grande varejista brasileira processa mais de 730 TB de dados em 6 meses através de sua infraestrutura distribuída. Sem métricas estruturadas, entender onde está o gargalo de performance entre milhões de requisições seria impossível. Métricas são a base que permite transformar dados brutos em respostas quantitativas: “qual a latência P95?”, “quantos erros por minuto?”, “qual o throughput atual?”.

Prometheus é uma das ferramentas mais adotadas para métricas e um projeto graduado da CNCF. Organizações com práticas maduras de observabilidade tipicamente começam com métricas como primeiro passo, pois permitem detectar anomalias em tempo real e responder incidentes mais rapidamente.

O que são Métricas?

Métricas são valores numéricos observados e coletados ao longo do tempo, geralmente organizados como séries temporais. Representam estado, comportamento ou desempenho de sistemas e aplicações. Cada métrica consiste em:

1. Nome: Identificador único (ex: http_requests_total)
2. Labels/Dimensões: Metadados para filtragem (ex: {method="GET", status="200"})
3. Valor numérico: O valor observado ou coletado
4. Timestamp: Momento da coleta

Formato Prometheus (exposição):

http_requests_total{method="GET", status="200"} 12345 1622745600000
http_requests_total{method="POST", status="500"} 67 1622745600000

Diferença: Métricas vs Logs vs Traces

Além de saber o que medir, é importante entender como modelar essa medição. O modelo de instrumentação do Prometheus define quatro tipos principais de métricas, cada um com características específicas de uso.

Os 4 Tipos de Métricas no Modelo Prometheus

Counter, Gauge, Histogram e Summary são tipos de métrica no modelo de instrumentação do Prometheus, amplamente utilizados para representar diferentes padrões de medição. Outras ferramentas podem ter classificações diferentes, mas esses conceitos são aplicáveis em diversos contextos.

Counter

Valor que só aumenta, reiniciando em zero quando o processo é reiniciado.

Características:

• Monotonicamente crescente
• Reinicia em zero quando o processo é reiniciado
• Usado para calcular taxas (ex: requisições por segundo via rate())

Exemplos:

• http_requests_total → Total de requisições HTTP
• errors_total → Total de erros
• bytes_transmitted_total → Bytes transmitidos

Uso típico:

# Taxa de requisições por segundo nos últimos 5 minutos
rate(http_requests_total[5m])

# Taxa de erros por minuto
rate(errors_total[1m]) * 60

Gauge

Valor que pode subir ou descer, representa o estado atual.

Características:

• Instantâneo do momento
• Pode subir ou descer livremente
• rate() não faz sentido para gauges (pois não são monotonicamente crescentes)
• Usado para mostrar tendências e estado atual

Exemplos:

• cpu_usage_percent → Uso de CPU atual
• memory_bytes → Memória em uso
• active_connections → Conexões ativas
• temperature_celsius → Temperatura

Uso típico:

# Valor atual (instantâneo)
cpu_usage_percent

# Média nos últimos 5 minutos
avg_over_time(cpu_usage_percent[5m])

# Máximo nos últimos 1 hora
max_over_time(memory_bytes[1h])

Histogram

Distribui valores observados em buckets cumulativos predefinidos, permitindo estimar quantis a partir dos buckets definidos no momento da consulta.

Características:

• Bucket counters são cumulativos (cada bucket inclui valores de buckets menores)
• Permite estimar quantis via histogram_quantile() na consulta
• Permite agregar métricas de múltiplas instâncias
• Mais flexível que summary para sistemas distribuídos

Exposição (três séries geradas):

# Bucket counters
http_request_duration_seconds_bucket{le="0.1"} 100
http_request_duration_seconds_bucket{le="0.5"} 150
http_request_duration_seconds_bucket{le="1.0"} 180
http_request_duration_seconds_bucket{le="+Inf"} 200

# Sum of all values
http_request_duration_seconds_sum 123.4

# Count of observations
http_request_duration_seconds_count 200

Uso típico:

# Latência P95 nos últimos 5 minutos (agregando múltiplas instâncias)
histogram_quantile(0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

# Latência P99
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

Summary

Calcula quantis no cliente (agente de instrumentação) no momento da observação.

Características:

• Quantis calculados no lado do cliente
• Os quantis de summary não são agregáveis corretamente entre instâncias (diferente de histogram)
• Quantis dependem da configuração do cliente e podem ter variação
• Menos flexível, mas evita custo de armazenamento de buckets

Exposição:

http_request_duration_seconds{quantile="0.5"} 0.12
http_request_duration_seconds{quantile="0.9"} 0.35
http_request_duration_seconds{quantile="0.99"} 0.89
http_request_duration_seconds_sum 123.4
http_request_duration_seconds_count 200

Uso típico:

# Valor direto (já calculado)
http_request_duration_seconds{quantile="0.99"}

Histogram vs Summary: Quando usar cada?

Depois de entender os tipos de métricas, vale a pena conhecer um conjunto de sinais que se tornou referência para monitoramento de serviços.

Golden Signals: As Métricas Essenciais

Golden signals são as quatro métricas fundamentais descritas no Google SRE Book. Elas fornecem uma visão essencial da saúde de um serviço e são um ponto de partida importante para observar sistemas distribuídos.

Nota: Golden signals são um ponto de partida útil. Equipes maduras também acompanham métricas de negócio (conversão, receita) e métricas específicas da aplicação (jornadas críticas, funis).

Os percentis P95 e P99 são quantis frequentemente usados para medir latência. P95 significa que 95% das requisições tiveram latência igual ou inferior a esse valor; P99 representa o limite para 99% das requisições.

Métricas SLI/SLO

SLI (Service Level Indicator): Métrica que mede aspecto do serviço (ex: latência P95).

SLO (Service Level Objective): Objetivo para o SLI (ex: P95 < 200ms em 99.9% das requisições).

Exemplo:

Nota: Exemplos simplificados para fins didáticos. Na prática, o SLI de disponibilidade deve refletir a definição de sucesso específica do serviço.

Após entender os tipos de métricas e os sinais essenciais, o próximo passo é compreender como essas métricas são representadas como séries temporais.

Data Model do Prometheus

Séries Temporais

Formato: <metric_name>{<label_name>=<label_value>, ...} <value> <timestamp>

Exemplo:

http_requests_total{method="GET", status="200", endpoint="/api/users"} 12345 1622745600000

Componentes:

Labels aumentam o poder analítico das métricas, permitindo filtrar e agrupar dados. Porém, cada combinação única de labels cria uma nova série temporal — e isso pode escalar rapidamente.

Cardinalidade

Definição: Número de séries temporais únicas geradas por uma métrica.

Fórmula matemática:

S_total = |C₁| × |C₂| × ... × |Cₙ|

Onde:

• S_total = Número total de séries
• Cᵢ = Conjunto de valores possíveis para cada label i

Exemplo prático:

Métrica http_requests_duration_seconds com labels:

• method: 4 valores (GET, POST, PUT, DELETE)
• status: 3 valores (2xx, 4xx, 5xx)
• endpoint: 100 valores

S_total = 4 × 3 × 100 = 1.200 séries

Explosão de Cardinalidade

Problema: Labels com cardinalidade alta (ex: user_id, request_id) geram milhões de séries.

Exemplo ruim:

http_requests_total{user_id="12345", request_id="abc-123-def"}
# Resultado: milhões de séries → performance degradada

Mitigações:

1. Evite IDs únicos como labels (user_id, request_id, session_id)
2. Limite valores possíveis de cada label
3. Prefira modelagens agregáveis e evite multiplicar labels de alta cardinalidade
4. Monitore volume de séries ativas e valide modelagem antes de produção

Com a teoria de métricas, tipos e modelagem de dados estabelecida, vale a pena ver como esses conceitos se aplicam em cenários reais.

Casos de Uso Reais com Métricas

Marisa: Métricas de Performance em E-commerce

A Marisa é uma das maiores varejistas de moda do Brasil, com mais de 11 milhões de downloads do app e 70% das vendas digitais concentradas no mobile.

Desafio:

• Monitorar performance de e-commerce com milhões de requisições
• Entender gargalos de latência em tempo real
• Correlacionar métricas de infraestrutura com experiência do usuário

Métricas implementadas:

• Latência P95: Tempo de carregamento de páginas
• Throughput: Requisições por segundo nos picos
• Saturação: Uso de CPU/memória na origem vs borda
• Error rate: Taxa de erros HTTP por endpoint

Resultados verificados:

• 85% do tráfego entregue pela infraestrutura distribuída
• 730 TB transferidos sem impacto na origem
• 4.3 TB/dia de imagens processadas e otimizadas
• Melhoria em First Contentful Paint, Speed Index e Time to Interactive

Aprendizado: Métricas bem estruturadas permitem correlacionar performance de infraestrutura com experiência digital em escala, transformando dados operacionais em decisões de negócio.

B2W: Métricas de Segurança em Escala

A B2W Digital reúne algumas das maiores plataformas de e-commerce da América Latina, com 2 bilhões de visitas por ano e 17 milhões de clientes ativos.

Desafio:

• Monitorar segurança em milhões de conexões diárias
• Detectar ataques em tempo real
• Medir eficácia de mitigação

Métricas implementadas:

• Taxa de bloqueios: Requisições bloqueadas por segundo
• Tipos de ataque: DDoS, SQL injection, XSS por categoria
• Latência de mitigação: Tempo entre detecção e bloqueio
• Error rate por regra: Eficácia de cada regra de Firewall

Resultados verificados:

• Milhões de ataques bloqueados automaticamente
• Transformação de eventos em insights em tempo real
• Integração de métricas com SIEM via Data Streaming
• Visibilidade completa do ambiente em dashboards

Aprendizado: Métricas não servem apenas para performance — são fundamentais também para segurança operacional, permitindo medir eficácia de defesas e tempo de resposta a incidentes.

Coletar métricas é apenas parte do trabalho. Extrair sinal útil depende de saber agregar os dados corretamente.

Agregação de Métricas

Tipos de Agregação

Agregação por Labels

# Soma de requisições por método (agrega todos os endpoints)
sum by (method) (rate(http_requests_total[5m]))

# Média de latência por serviço
avg by (service) (latency_seconds)

# Máximo de CPU por região
max by (region) (cpu_usage_percent)

Agregação Temporal

# Média de uma métrica nos últimos 5 minutos
avg_over_time(cpu_usage_percent[5m])

# Máximo em 1 hora
max_over_time(memory_bytes[1h])

# Mínimo em 1 dia
min_over_time(active_connections[1d])

Com os conceitos de métricas, tipos, modelagem e agregação apresentados, as perguntas frequentes a seguir ajudam a consolidar o aprendizado.

Perguntas Frequentes

O que são métricas?

Métricas são valores numéricos observados e coletados ao longo do tempo que representam estado, comportamento ou desempenho de sistemas. Organizam-se como séries temporais com nome, labels e timestamp. Respondem perguntas como “qual a taxa de erro atual?”, “a latência está dentro do SLO?”. Diferem de logs (eventos) e traces (jornadas).

Quais são os 4 tipos de métricas?

Os quatro tipos no modelo Prometheus são: Counter (valores que só aumentam, ex: requisições totais), Gauge (valores que sobem e descem, ex: CPU %), Histogram (distribuição em buckets cumulativos, permite estimar quantis na consulta), e Summary (quantis calculados no cliente). Use histogram por padrão para sistemas distribuídos.

Qual a diferença entre counter e gauge?

Counter é um valor que só aumenta, reiniciando em zero quando o processo é reiniciado, usado para calcular taxas (ex: rate()). Gauge é um valor que pode subir ou descer, representa o estado atual (ex: CPU, memória). Use counter para totais acumulados, gauge para instantâneos.

O que são golden signals?

Golden signals são as quatro métricas essenciais descritas pelo Google SRE: Latência (tempo de resposta), Tráfego (demanda), Erros (taxa de falha) e Saturação (uso de recursos). Elas fornecem uma visão essencial da saúde de um serviço e são a base para SLIs/SLOs.

O que é cardinalidade em métricas?

Cardinalidade é o número de séries temporais únicas geradas por uma métrica, calculado pelo produto dos valores possíveis de cada label. “Explosão de cardinalidade” ocorre quando labels com muitos valores (user_id, request_id) geram milhões de séries, degradando performance.

Histogram ou Summary: quando usar cada?

Use Histogram por padrão (agrega múltiplas instâncias e permite estimar quantis na consulta a partir dos buckets definidos). Use Summary apenas quando precisar de quantis calculados no cliente e não precisar agregá-los entre instâncias. Histogram é mais flexível e adequado para sistemas distribuídos.

Como evitar explosão de cardinalidade?

Evite labels com valores únicos (user_id, request_id), limite os valores possíveis de cada label, prefira modelagens agregáveis, reduza ou agregue dimensões de alta cardinalidade antes da exposição quando possível, e monitore o número de séries ativas.

Conclusão

Métricas são a base da observabilidade. Elas transformam o comportamento de sistemas em dados numéricos que podem ser consultados, alertados e correlacionados. Os quatro tipos do modelo Prometheus — Counter, Gauge, Histogram e Summary — cobrem a maioria dos cenários de monitoramento.

Conceitos-chave:

• Métricas = Valores numéricos coletados ao longo do tempo para representar estado, comportamento ou desempenho
• 4 tipos (Prometheus): Counter (só sobe), Gauge (sobe/desce), Histogram (buckets cumulativos), Summary (quantis no cliente)
• Golden signals: Latência, Tráfego, Erros, Saturação
• Cardinalidade: Cuidado com labels de alta cardinalidade
• Prometheus: Projeto graduado da CNCF, amplamente adotado

Próximos passos:

Para iniciantes:

1. Entenda os 4 tipos de métricas
2. Implemente golden signals em sua aplicação
3. Use Prometheus para exposição

Para times de operações:

1. Configure SLOs baseados em SLIs
2. Monitore cardinalidade de suas métricas
3. Integre com Real-Time Metrics para dashboards

Para empresas maduras:

1. Otimize consultas PromQL
2. Implemente alertas baseados em SLOs
3. Use histogramas para SLIs de latência

Quer visualizar métricas em tempo real com latência de segundos? Conheça Real-Time Metrics e Data Stream para coleta e análise de métricas em escala. Comece grátis — 1M requests/mês.