1) Padronização de nomes de métricas e labels

Um erro recorrente é a ausência de convenções de nomenclatura e a utilização indiscriminada de labels de alto cardinalidade. Métricas mal nomeadas dificultam filtragem, compreensão e a escalabilidade de consultas em Grafana ou outras plataformas. Estabelecer padrões facilita a vida da equipe, reduz ruído e melhora a performance do data plane.

• Defina um conjunto mínimo de labels estáveis para filtragem (por exemplo: service, region, instance) e evite labels com IDs de usuário, session_id ou caminhos dinâmicos.
• Use nomes de métricas consistentes: sufixos como _total para contadores, _gauge para valores que variam livremente, e padrões como myservice_request_total.
• Considere normalizar rotas e endpoints para reduzir cardinalidade quando possível (por exemplo, endpoint=”/api/v1/resource” em vez de “/api/v1/resource/123”).
• Mantenha consistência entre serviços: o mesmo tipo de métrica deve seguir o mesmo conjunto de labels em toda a base observável.

Exemplos:

• Errado: http_requests_total{method=”GET”, path=”/api/v1/resource/12345″, status=”200″}
• Certo: http_requests_total{service=”billing”, method=”GET”, status=”200″, endpoint=”/api/v1/resource”}

2) Configuração de scraping e intervalos

A configuração de scraping impacta diretamente na carga do Prometheus e na qualidade dos dados. Intervalos muito curtos em serviços com métricas de baixa cardinalidade geram ruído desnecessário, enquanto intervalos excessivamente longos podem perder picos de latência. Alinhe scrape_interval, scrape_timeout e as descobertas de serviço com a criticidade das métricas.

• Ajuste o scrape_interval conforme a criticidade e a taxa de emissão das métricas. Para serviços de alto tráfego, 15s a 30s costuma funcionar bem; para métricas menos dinâmicas, 1m ou mais é aceitável.
• Defina scrape_timeout menor que o interval para evitar falhas de scrape não gerenciadas. Ex.: scrape_interval: 30s; scrape_timeout: 10s.
• Use descobertas de serviço estáveis (Kubernetes, Consul, etc.) com rótulos consistentes e evite endpoints instáveis que gerem métricas raras.
• Se possível, utilize TLS/MTLS e autenticação para endpoints sensíveis e mantenha path padrão (/metrics) ou ajuste conforme necessário.

Dicas rápidas: agrupe métricas com criticidade alta em scrapes mais frequentes e reduza a frequência para métricas administrativas menos relevantes.

3) Alertas: regras mal definidas e severidade

Alertas mal calibrados geram ruído, dificultam a detecção de incidentes reais e sobrecarregam equipes. Planeje regras com neutralidade de falhas, tempo de espera (for) adequado e rotas de resolução claras no Alertmanager.

• Evite regras simples como “se erro > 0”, prefira taxas com janela temporal e coerção de falhas, por exemplo 5xx / total em 5 minutos.
• Avalie o for para evitar notificações de ruídos imediatos; use valores proporcionais ao tempo de resposta esperado pelo serviço.
• Utilize labels consistentes e o roteamento do Alertmanager para agrupar incidentes por serviço, ambiente e prioridade.
• Documente as regras com descrições claras, para facilitar a operação e auditoria.

Exemplo de regra mais robusta (PromQL):

ALERT HighErrorRate
  IF sum(rate(http_requests_total{status=~"5.."}[5m])) 
     / sum(rate(http_requests_total[5m])) > 0.05
  FOR 10m
  LABELS { severity="critical", service="api" }
  ANNOTATIONS {
    summary = "Alto percentual de erros 5xx no serviço API",
    description = "A taxa de erros 5xx excedeu 5% nos últimos 5 minutos por mais de 10 minutos."
  }

Essa abordagem evita notificações falsas e facilita a priorização no time de SRE.

4) Consultas PromQL eficientes e dashboards confiáveis

Consultas PromQL mal elaboradas podem se tornar gargalos, especialmente em grandes ambientes com alta cardinalidade. Foque em previsões estáveis, usando regras de gravação (recording rules) para pré-computar agregações caras e reduzir o custo de dashboards em Grafana.

• Prefira consultas com filtros explícitos (por exemplo, service, region) para evitar varreduras de grandes conjuntos de rótulos.
• Use windowing adequado: rate() e increase() requerem janelas que reflitam o comportamento da métrica; janelas muito curtas podem ser ruidosas, janelas muito longas podem mascarar picos.
• Crie recording rules para métricas compostas (ex.: request_rate_per_service) e reuse-as nos dashboards.
• Avalie cardinalidade: rótulos com muitas possibilidades geram muitos dados preservar; reduza rótulos desnecessários.

Exemplo de melhoria de PromQL (antes e depois):

# Mau exemplo (sem filtro de serviço, janela muito curta)
sum(rate(http_requests_total[1m]))

# Melhor exemplo (filtro por serviço e janela adequada)
sum by (service) (
  rate(http_requests_total{service="api-gateway"}[5m])
)

# Taxa de erro de serviço (usando filtragem explícita)
sum by (service) (
  rate(http_requests_total{service="api-gateway", status=~"5.."}[5m])
) / sum by (service) (
  rate(http_requests_total{service="api-gateway"}[5m])
)

Observação: para consultas repetitivas, implemente recording rules como api_gateway_request_rate_5m para reduzir carga durante a correção de problemas e o tuning de dashboards.