Métricas na Observabilidade: Guia Avançado

Se os logs são a biografia detalhada de um evento e os traces são o mapa de sua jornada, as Métricas são os sinais vitais do paciente em tempo real. No ecossistema da observabilidade, as métricas representam a camada mais eficiente e econômica de dados, permitindo que engenheiros visualizem a saúde de milhares de microsserviços em uma única tela de dashboard.

Enquanto um log diz “O usuário X falhou ao logar às 14:00 devido a erro Y”, uma métrica diz “A taxa de erro de login aumentou 5% nos últimos 10 minutos”. Para gestores de TI e SREs, as métricas são a primeira linha de defesa: elas dizem o que está acontecendo, disparando o alerta que levará à investigação do porquê (logs) e do onde (traces). Este artigo disseca a anatomia das métricas, os desafios da cardinalidade e como estruturá-las para monitoramento de alta performance.

Definição Técnica: O Que é uma Métrica?

Uma métrica é, essencialmente, um valor numérico medido ao longo do tempo (Time Series). Diferente de logs não estruturados, as métricas são altamente compressíveis e otimizadas para cálculos matemáticos rápidos (somas, médias, percentis).

No padrão moderno (como o utilizado pelo Prometheus), uma métrica é composta por:

• Nome: O identificador do que está sendo medido (ex: `http_requests_total`).
• Labels (Dimensões): Pares de chave-valor que dão contexto (ex: `method=”POST”`, `status=”500″`, `region=”us-east-1″`).
• Valor: O número atual (ex: `1024`).
• Timestamp: O momento da coleta.

O poder das métricas reside nas Labels. Elas permitem a agregação dinâmica. Você pode perguntar ao sistema “qual a taxa de erro total?” ou “qual a taxa de erro apenas no servidor X?”, tudo a partir do mesmo conjunto de dados.

Tipos Primitivos de Métricas

Para construir dashboards de monitoramento em tempo real eficazes, é crucial escolher o tipo de dado correto. Usar um “Gauge” onde deveria ser um “Counter” resultará em gráficos enganosos.

Counters (Contadores)

Um valor que apenas sobe (monotônico). Exemplo: Número total de requisições HTTP ou tarefas completadas. Ele nunca diminui, a menos que o sistema reinicie. São fundamentais para calcular taxas (`rate()`) por segundo.

Gauges (Medidores)

Um valor que pode subir e descer arbitrariamente. Exemplo: Uso de memória RAM, temperatura da CPU ou número de goroutines em execução. Eles mostram o estado instantâneo do sistema (snapshot).

Histograms e Summaries

Utilizados para medir distribuições estatísticas, como a duração de requisições ou tamanho de respostas. Eles são vitais para calcular Percentis (P95, P99). Dizer que a “latência média é 200ms” esconde o fato de que 1% dos seus usuários (P99) pode estar sofrendo com 5 segundos de espera. Histogramas revelam essa verdade.

Exemplos de Métricas em um Dashboard

Este dashboard exemplifica a aplicação de práticas de SRE (Site Reliability Engineering) na observabilidade, focando na relação entre SLOs (metas de disponibilidade) e SLIs (desempenho real medido).

A métrica de Availability indica se o sistema está online, enquanto o Error Budget Left (Orçamento de Erro) quantifica a margem de falha restante antes que a meta seja violada. Essa abordagem muda o foco da “perfeição técnica” para o gerenciamento de risco, permitindo que as equipes visualizem rapidamente o quanto ainda podem arriscar em inovações sem comprometer a estabilidade acordada para o período.

 
Complementando a disponibilidade, o painel utiliza o Apdex Score para medir a satisfação do usuário em relação ao tempo de resposta (latência), classificando a performance como satisfatória ou frustrante com base em um threshold (limiar) específico.

O grande valor de observabilidade aqui é a segmentação por Jornadas de Negócio (como “Checkout” ou “Ordem de Compra”), o que contextualiza as métricas técnicas: um erro na etapa de pagamento (Jornada 3) é visualmente priorizado sobre uma lentidão na vitrine, alinhando o monitoramento diretamente ao impacto financeiro e à experiência do cliente.

O Perigo da Alta Cardinalidade

O maior desafio técnico em sistemas de métricas é a Explosão de Cardinalidade. Cardinalidade refere-se ao número de combinações únicas de labels em suas métricas.

Se você adicionar uma label como `user_id` ou `ip_address` em uma métrica de `http_requests_total`, e você tiver 1 milhão de usuários, você gerará 1 milhão de séries temporais únicas para cada endpoint. Isso pode derrubar seu banco de dados de séries temporais (TSDB) e explodir sua conta de cloud.

Regra de Ouro: Nunca coloque dados com alta variação (como IDs de transação, e-mails ou UUIDs) em labels de métricas. Esses dados pertencem aos Logs ou Traces. Mantenha as métricas para dados agregáveis (região, versão do deploy, código de status).

Metodologias de Monitoramento: USE vs. RED

Ter os dados não é suficiente; é preciso saber o que olhar. Existem duas metodologias padrão de mercado para organizar suas métricas:

• Método USE (Para Infraestrutura): Focado em recursos físicos (CPU, Disco, Memória).
  • Utilization: Quanto tempo o recurso estava ocupado?
  • Saturation: Quanto trabalho está na fila esperando (Load Average)?
  • Errors: Ocorreram erros de hardware/transmissão?
• Método RED (Para Serviços): Focado na experiência do usuário e microsserviços.
  • Rate: Número de requisições por segundo (tráfego).
  • Errors: Número de requisições que falharam.
  • Duration: Quanto tempo as requisições levaram (Latência).

Aplicar o método RED em seus dashboards de telemetria garante que você esteja monitorando o que realmente impacta o cliente final, e não apenas se o servidor está ligado.

Os Quatro Sinais de Ouro (Golden Signals)

O livro de SRE do Google define os “Four Golden Signals” como o padrão mínimo para monitoramento de sistemas distribuídos. Se você só pode medir quatro coisas, meça estas:

1. Latência: O tempo que leva para servir uma requisição. Importante distinguir latência de sucesso vs. latência de erro.
2. Tráfego: A demanda colocada sobre o sistema (req/seg ou I/O rate).
3. Erros: A taxa de falha (explícita como 500s, ou implícita como respostas vazias).
4. Saturação: O quão “cheio” está o seu serviço. A métrica que avisa antes da quebra (ex: Pool de conexões de banco de dados em 90%).

Para aprofundar-se, consulte o capítulo oficial sobre Monitoring Distributed Systems do Google.

Armazenamento: TSDBs (Time Series Databases)

Métricas exigem bancos de dados especializados. Tentar armazenar histórico de métricas em um banco relacional (MySQL/PostgreSQL) é ineficiente em escala. Soluções como Prometheus, InfluxDB e VictoriaMetrics são projetadas para escrita massiva e compressão agressiva.

Essas TSDBs permitem retenção eficiente, descartando dados granulares antigos (Downsampling) para economizar espaço, mantendo apenas médias diárias ou semanais para análises de tendência de longo prazo (Capacity Planning).

Conclusão

As métricas são a bússola da navegação operacional. Sem elas, você voa às cegas, dependendo de reclamações de usuários para saber que algo quebrou. No entanto, coletar métricas indiscriminadamente cria ruído e custos desnecessários.

A arte da engenharia de SRE está em selecionar os indicadores que realmente refletem a saúde do negócio, aplicar as labels corretas para permitir o “drill-down” e configurar alertas que sejam acionáveis. Métricas bem implementadas transformam a ansiedade da incerteza na confiança do controle.

Caso tenha interesse em conhecer mais sobre nossos modelos comerciais para este tipo de serviço, fale com nossos especialistas.