Prometheus: coleta e consulta de métricas em produção

O que é Prometheus e o modelo pull

Prometheus é um sistema de monitoramento e alertas open-source criado pelo SoundCloud em 2012 e doado à CNCF em 2016, tornando-se o padrão de facto para coleta de métricas em ambientes cloud-native. O modelo pull do Prometheus significa que o próprio servidor faz scraping dos targets configurados em intervalos regulares — tipicamente 15 ou 30 segundos — fazendo requisições HTTP GET para o endpoint /metrics de cada serviço. Isso contrasta com o modelo push usado por sistemas como StatsD, onde as aplicações enviam métricas para um servidor central. O modelo pull simplifica a configuração de targets, permite detecção automática de serviços caídos (pois scrape falha), e centraliza no Prometheus a definição de quais serviços monitorar, sem necessidade de configuração nos serviços monitorados.

Exporters — expondo métricas no formato Prometheus

Exporters são processos que coletam métricas de sistemas que não expõem nativamente o formato Prometheus e as convertem para o formato de texto esperado pelo scraper. O node_exporter coleta métricas de hardware e sistema operacional Linux — CPU, memória, disco, rede — e é instalado em cada servidor monitorado. O kube-state-metrics exporta métricas sobre o estado dos objetos Kubernetes — pods, deployments, namespaces, persistentvolumeclaims. Há exporters para PostgreSQL, MySQL, Redis, Kafka, Elasticsearch, nginx e centenas de outras tecnologias, todos mantidos pela comunidade Prometheus. Para aplicações próprias, os client libraries do Prometheus — disponíveis para Go, Java, Python, Ruby e .NET — permitem expor métricas customizadas diretamente no processo da aplicação sem necessidade de exporter externo.

Scrape config — configurando o que coletar

A configuração do Prometheus define os jobs de scraping no arquivo prometheus.yml, especificando os targets — hosts e portas — e o intervalo de coleta para cada job. Targets podem ser configurados estaticamente com IPs fixos ou de forma dinâmica via service discovery integrado ao Kubernetes, Consul, EC2, Azure e outros provedores. No Kubernetes, o Prometheus usa anotações nos pods para descobrir automaticamente quais serviços devem ser coletados — pods com a anotação prometheus.io/scrape: "true" são adicionados automaticamente como targets. Relabeling permite transformar os labels dos targets antes do scraping, renomear labels e filtrar targets desnecessários, oferecendo controle fino sobre como as métricas são organizadas no Prometheus.

PromQL — queries de métricas

PromQL (Prometheus Query Language) é a linguagem de consulta funcional do Prometheus, projetada para trabalhar com dados de séries temporais. Operações fundamentais incluem: selecionar uma métrica por nome como http_requests_total, filtrar por labels como http_requests_total{status="500"}, calcular taxa de crescimento com rate(http_requests_total[5m]), e agregar entre instâncias com sum by (service)(rate(http_requests_total[5m])). Funções como histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) calculam o percentil 99 de latência a partir de histogramas. PromQL pode parecer complexa inicialmente, mas um conjunto pequeno de funções — rate, sum, histogram_quantile, increase, avg_over_time — cobre a maioria das queries de monitoramento em produção.

Alerting rules — definindo condições de alerta

Alerting rules no Prometheus são expressões PromQL que, quando verdadeiras por uma duração configurada, geram alertas enviados ao Alertmanager. Uma rule típica para alta taxa de erro seria rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.01 com duração de 5 minutos antes de disparar. Cada alerta tem labels que identificam o serviço afetado e anotações com o resumo do problema e um link para o dashboard relevante. O campo for evita falsos positivos em picos momentâneos, só disparando quando a condição persiste pelo tempo especificado. Alertas são agrupados por labels comuns — como service e environment — para evitar avalanche de notificações quando múltiplos serviços falham simultaneamente.

Alertmanager — roteando e silenciando alertas

O Alertmanager é o componente do ecossistema Prometheus responsável por receber alertas, deduplicar, agrupar e rotear para os canais de notificação corretos — Slack, PagerDuty, email, OpsGenie, webhook. A configuração de roteamento define hierarquias de receivers: alertas críticos de produção vão para PagerDuty 24/7, alertas de warning vão para Slack durante horário comercial. Inibições permitem suprimir alertas secundários quando um alerta primário está ativo — se o cluster inteiro está inacessível, não faz sentido receber alertas individuais de cada serviço. Silences são supressões temporárias para períodos de manutenção, criadas via interface web ou API, evitando ruído durante janelas planejadas de indisponibilidade.

Prometheus e Kubernetes — kube-state-metrics e node-exporter

No ecossistema Kubernetes, o Prometheus é tipicamente implantado via Helm chart do kube-prometheus-stack, que inclui o Prometheus, Alertmanager, Grafana, node-exporter e kube-state-metrics pré-configurados com dashboards e alerting rules prontos. O node-exporter roda como DaemonSet — uma instância em cada node — coletando métricas de hardware do servidor. O kube-state-metrics é um deployment que observa a API do Kubernetes e expõe o estado declarativo dos objetos: número de pods desejados vs disponíveis, status de deployments, condição de nodes. Métricas de pods individuais como uso de CPU e memória são coletadas via cAdvisor integrado ao kubelet, acessível no endpoint /metrics/cadvisor de cada node.

Retention e storage — quanto guardar

Por padrão, o Prometheus armazena dados localmente no TSDB com retenção de 15 dias, configurável via flag --storage.tsdb.retention.time. O armazenamento local é adequado para observabilidade de curto prazo mas não substitui soluções de longo prazo para análise histórica e capacity planning. O tamanho do storage cresce linearmente com o número de séries ativas e a frequência de scraping: uma instalação com 1 milhão de séries coletadas a cada 15 segundos consome aproximadamente 1-2 GB por dia. Para retenção além de 15 dias, o Prometheus pode ser configurado com remote_write para enviar dados para Thanos, Cortex, VictoriaMetrics ou Grafana Cloud, que oferecem storage distribuído e escalável para retenção de meses ou anos.

Thanos e Cortex para escala

Thanos estende o Prometheus adicionando storage de longo prazo em object storage como S3, GCS ou MinIO, alta disponibilidade com múltiplas réplicas deduplicadas, e queries globais federadas que consultam múltiplas instâncias Prometheus como se fossem uma só. A arquitetura do Thanos inclui sidecars que se conectam às instâncias Prometheus, um store gateway que serve dados do object storage, e um querier que agrega resultados. Cortex é uma alternativa que segue o modelo multitenant, adequado para plataformas que precisam isolar métricas entre diferentes clientes ou times. Ambos suportam a API do Prometheus, tornando-os transparentes para ferramentas como Grafana que já usam PromQL para queries. Para clusters Kubernetes de médio porte, Thanos com S3 é a solução de escala mais comum.

Conclusão

Prometheus se tornou o padrão de monitoramento de métricas em sistemas cloud-native pela combinação de modelo pull eficiente, PromQL expressivo, ecossistema vasto de exporters e integração nativa com Kubernetes. A simplicidade do formato de texto para exposição de métricas democratizou a instrumentação — qualquer serviço pode expor métricas com poucas linhas de código. Alerting rules declarativas e o Alertmanager com roteamento flexível completam o ciclo de monitoramento sem necessidade de ferramentas externas. Para escala além de uma única instância, Thanos e Cortex estendem o Prometheus sem mudar como desenvolvedores escrevem queries e configuram dashboards. Continue em: Fundamentos obrigatórios antes de produção.