Metrics: medindo comportamento e performance do sistema em produção

O que são métricas e por que diferem de logs

Métricas são medidas numéricas coletadas ao longo do tempo que representam o estado ou comportamento de um sistema de forma agregada — como a taxa de requisições por segundo, o percentil 99 de latência ou o uso atual de memória. Diferente de logs, que são eventos individuais com contexto textual rico, métricas são otimizadas para armazenamento compacto em séries temporais e consulta eficiente por intervalos de tempo. Um sistema pode gerar milhões de logs por minuto que seriam impossíveis de processar em tempo real para alertas, enquanto as mesmas informações comprimidas em métricas como taxa de erro e latência média podem ser consultadas em milissegundos. Métricas e logs se complementam: métricas detectam que algo está errado, logs explicam o contexto exato do problema.

Os 4 sinais dourados — latência, tráfego, erros, saturação

Os quatro sinais dourados definidos pelo Google SRE Book são o conjunto mínimo de métricas que todo sistema em produção deve monitorar. Latência mede o tempo que o sistema leva para responder a uma requisição, sempre diferenciando requisições bem-sucedidas de falhas — uma requisição que falha rápido mascara problemas se misturada com sucessos lentos. Tráfego quantifica a demanda sendo colocada sobre o sistema, como requisições por segundo, mensagens processadas ou transações concluídas. Erros medem a taxa de requisições que falham explicitamente com 5xx, implicitamente com respostas incorretas, ou por violação de SLO. Saturação mede o quanto o recurso mais constrito está sendo utilizado — CPU, memória, disco ou conexões de banco — indicando quando a capacidade está prestes a ser excedida.

Counters, gauges, histogramas e summaries

Counters são métricas que só crescem monotonicamente, como o total de requisições processadas ou bytes transmitidos — nunca decrementam, e o que interessa é a taxa de crescimento por segundo, calculada com funções como rate() no Prometheus. Gauges representam valores que sobem e descem no tempo, como uso atual de memória, número de conexões ativas ou temperatura de CPU. Histogramas coletam observações em buckets de tamanho configurável, permitindo calcular percentis aproximados — como p50, p95 e p99 de latência — com baixo overhead de armazenamento. Summaries calculam percentis exatos no cliente, mas são mais caros computacionalmente e não agregáveis entre instâncias, o que os torna menos úteis em ambientes com múltiplas réplicas de serviço.

Cardinalidade — o problema de métricas com muitas labels

Cardinalidade é o número de séries temporais únicas geradas por uma métrica, calculado como o produto dos valores possíveis de cada label. Uma métrica com labels service (10 valores), endpoint (50 valores) e status_code (20 valores) gera 10.000 séries temporais. Adicionar uma label de alta cardinalidade como user_id ou request_id pode explodir o número de séries para milhões, saturando o banco de métricas e tornando queries inviáveis — esse problema é conhecido como "cardinalidade explosiva". A regra prática é que labels devem ter cardinalidade baixa e previsível: status codes, regiões, serviços e environments são boas labels; IDs de usuário, UUIDs e hashes são proibidos como labels de métricas.

Time series databases — como métricas são armazenadas

Time series databases (TSDBs) são especializados em armazenar e consultar sequências de pontos de dados indexados por timestamp, com compressão otimizada para dados numéricos que mudam gradualmente. O Prometheus usa seu próprio TSDB local com compressão baseada em delta-of-delta para timestamps e XOR encoding para valores, atingindo taxas de compressão de 1-2 bytes por amostra. InfluxDB é outra TSDB popular com suporte a queries SQL-like via Flux. Para retenção de longo prazo e escala horizontal, Thanos e Cortex estendem o Prometheus adicionando storage remoto em objeto (S3, GCS) e queries federadas entre múltiplos Prometheus. VictoriaMetrics é uma alternativa de alta performance que suporta o protocolo do Prometheus com melhor eficiência de storage.

Métricas de negócio — além de CPU e memória

Métricas técnicas de infraestrutura são necessárias mas insuficientes para entender a saúde do negócio. Métricas de negócio medem o valor entregue ao usuário: taxa de conversão de checkout, tempo médio de processamento de pedidos, volume de transações por hora e taxa de abandono de carrinho. Essas métricas conectam a visibilidade técnica ao impacto real — um spike de CPU pode não ser crítico, mas uma queda de 20% na taxa de conversão em horário comercial é sempre urgente. Instrumentar métricas de negócio requer que desenvolvedores exponham contadores e gauges específicos do domínio usando os SDKs de métricas (OpenTelemetry, Prometheus client libraries), não apenas confiar em métricas geradas automaticamente por frameworks.

Alertas baseados em métricas

Alertas eficazes são baseados em sintomas observáveis pelo usuário, não em causas de infraestrutura. Um alerta em "taxa de erro acima de 1% por 5 minutos" é superior a um alerta em "CPU acima de 80%", porque o primeiro indica diretamente impacto no usuário enquanto o segundo pode ou não ser problemático dependendo do workload. Alertas baseados em percentis de latência — como p99 de latência acima de 2 segundos — capturam degradações que médias ocultam, já que a média pode ser baixa mesmo quando 1% dos usuários experimenta timeouts. Thresholding estático é simples mas frágil; alertas baseados em SLO error budget queimado oferecem mais sinal sobre urgência real, pois consideram o histórico de conformidade do serviço.

RED method e USE method

RED (Rate, Errors, Duration) e USE (Utilization, Saturation, Errors) são frameworks que padronizam quais métricas coletar dependendo do tipo de componente. O método RED foi desenvolvido por Tom Wilkie da Weaveworks para serviços de requisição: medir a Taxa de requisições por segundo, a taxa de Erros e a Duração (latência) de cada requisição. O método USE foi desenvolvido por Brendan Gregg para recursos de infraestrutura: medir a Utilização percentual do recurso, a Saturação (fila de espera), e os Erros. Para um serviço web, aplica-se RED; para CPU, disco, rede e memória, aplica-se USE. Combinar os dois métodos cobre tanto a perspectiva do serviço quanto da infraestrutura subjacente.

Métricas em microsserviços — agregação e correlação

Em arquiteturas de microsserviços com dezenas ou centenas de serviços, a gestão de métricas requer padrões consistentes de naming, labeling e aggregation. Cada serviço deve expor métricas com o mesmo conjunto de labels — como service, version, environment e region — para que queries agregadas façam sentido entre serviços diferentes. Dashboards de serviço usam variáveis de template para alternar entre instâncias sem duplicar configuração. A correlação de métricas com traces é fundamental: quando um alerta de latência dispara, navegar diretamente para traces do período afetado permite identificar o serviço causador sem suposições. Métricas de upstream e downstream conectadas pelo mesmo request ID criam uma visão completa da cadeia de dependências.

Conclusão

Métricas são a base quantitativa da observabilidade, transformando o comportamento contínuo do sistema em números consultáveis e alertáveis. Os quatro sinais dourados fornecem o mínimo viável de cobertura para qualquer serviço em produção, enquanto métricas de negócio conectam a saúde técnica ao valor entregue ao usuário. Escolher os tipos corretos — counters para taxas, gauges para estados, histogramas para distribuições — e controlar a cardinalidade evita os problemas mais comuns com sistemas de métricas em escala. Frameworks como RED e USE estruturam o pensamento sobre o que medir, reduzindo a tentação de instrumentar tudo sem critério. Continue em: Fundamentos obrigatórios antes de produção.