Antes de perceber o Prometheus, pensava na monitorização como algo que recolhia logs e os mostrava em algum lado. Armazenas eventos, pesquisas, encontras o problema. Esse modelo mental não está completamente errado, mas leva-te a construir as coisas erradas.
O Prometheus não é um sistema de logs. Não se importa com eventos individuais. Interessa-se pelo estado atual do teu sistema, amostrado ao longo do tempo. Essa distinção parece subtil e muda completamente a forma como pensas sobre observabilidade.
O Modelo Pull
A maior parte das ferramentas de monitorização que tinha usado antes eram baseadas em push. A tua aplicação envia dados para um coletor. O Prometheus inverte isto. Faz pull. A cada poucos segundos, o Prometheus faz um pedido HTTP ao endpoint /metrics da tua aplicação e lê o que lá estiver.
A primeira vez que vi isto achei que estava ao contrário. Porque é que quererias que o sistema de monitorização controlasse o timing? Mas faz sentido quando pensas melhor. Se uma aplicação deixar de responder, o Prometheus sabe imediatamente porque o scrape falha. Com sistemas baseados em push, tens de monitorizar separadamente se o agente ainda está a enviar dados. Com o Prometheus, o silêncio é em si mesmo um sinal.
Também significa que a tua aplicação não precisa de saber nada sobre onde está a ser monitorizada. Expões o /metrics, e quem estiver a fazer scraping é problema de outra camada. Separação limpa.
O Modelo de Dados
Cada métrica no Prometheus é uma combinação de um nome e um conjunto de labels. As labels são pares chave-valor que te permitem fatiar a mesma métrica de formas diferentes.
Pensa na duração de pedidos HTTP. Podes ter uma métrica chamada http_request_duration_seconds com labels para method, route e status_code. Essa única métrica, com as labels certas, permite-te responder: quanto tempo demoram os pedidos GET, quanto tempo demoram os pedidos POST a /orders, quanto tempo demoram os pedidos que retornam 500. Tudo a partir de uma coisa só.
Cometi este erro no início. Estava a criar métricas separadas para cada rota, o que tornava as queries PromQL confusas e os dashboards Grafana frágeis. As labels são a ferramenta certa. Uma métrica com boas labels bate dez métricas com nomes fixos.
Counters, Gauges, Histogramas
O Prometheus tem quatro tipos de métricas. Uso três regularmente.
Os counters só sobem. Total de pedidos processados, total de erros, total de bytes enviados. Fazem reset quando o processo reinicia, o que não é problema porque os queries são feitos em taxas, não em valores absolutos. rate(http_requests_total[5m]) dá-te pedidos por segundo nos últimos cinco minutos, independentemente de reinicios.
Os gauges sobem e descem. Uso atual de memória, número de ligações ativas, profundidade de fila. Fazes query ao valor atual porque é o que importa.
Os histogramas são os mais úteis e os mais mal compreendidos. Registam a distribuição de valores, não apenas a contagem. Para latência isto é crítico. Uma média diz-te muito pouco. Um histograma permite calcular o percentil 95 ou 99, que é onde está a dor real dos utilizadores. A métrica http_request_duration_seconds que a biblioteca prometheus-net cria automaticamente é um histograma. Trata-a como tal.
PromQL Vale a Pena Aprender a Sério
O PromQL é a linguagem de query do Prometheus e é genuinamente diferente do SQL. A curva de aprendizagem é real. Mas vale o investimento porque, uma vez que a percebes, consegues responder a quase qualquer pergunta sobre o teu sistema diretamente a partir dos dados que já estás a recolher.
O que me apanhou de surpresa no início: quase sempre queres rate() nos counters, não o valor bruto. O intervalo de tempo entre parênteses retos ([5m]) é uma janela de lookback, não um agrupamento. E o by nas agregações funciona como o GROUP BY no SQL, mas especificas as dimensões que queres manter, não as que queres colapsar.
Passa uma tarde no browser de expressões do Prometheus a escrever queries sobre os teus próprios dados. Encaixa mais depressa do que ler documentação.
Onde Entra o Grafana
O Prometheus tem a sua própria UI. É adequada para escrever e testar queries, mas não é onde queres passar tempo a observar dados de produção. Esse é o trabalho do Grafana.
O Grafana fala com o Prometheus como fonte de dados e transforma queries PromQL em painéis. A ligação é direta. O que importa é que o Grafana não armazena nada neste setup. Todos os dados vivem no Prometheus. O Grafana é apenas uma camada de renderização. Podes mudar os teus dashboards, apagá-los, reconstruí-los do zero, e os dados de métricas subjacentes ficam intactos.
É uma boa forma de pensar nisto: o Prometheus é a base de dados. O Grafana é a ferramenta de reporting. Fazem trabalhos diferentes e devem ser configurados separadamente.
Retenção e Armazenamento
Por defeito, o Prometheus guarda dados durante 15 dias. É suficiente para dashboards operacionais, mas não para tendências de longo prazo. Se quiseres meses de histórico, tens duas opções: aumentar a retenção e dar mais disco ao Prometheus, ou usar armazenamento remoto como Thanos ou Cortex para enviar dados para outro lado.
Para a maioria dos projetos em que trabalhei, 30 dias de retenção local cobre 90% das perguntas que alguém efetivamente faz. As conversas sobre "como estava o uso de memória há seis meses" acontecem menos frequentemente do que pensas, e quando acontecem, normalmente consegues responder com notas de deployment e registos de incidentes em vez de métricas brutas.
O Que Diria a Mim Mesmo Mais Cedo
Começa com os defaults. A biblioteca prometheus-net oferece métricas HTTP, métricas de runtime e métricas de processo sem configuração adicional. Só isso é mais útil do que a maior parte da instrumentação personalizada que já vi pessoas construírem do zero.
Adiciona métricas personalizadas apenas quando tens uma pergunta específica que os defaults não conseguem responder. "Quantas ordens estão no estado pendente agora" é uma boa razão para adicionar um gauge. "Devia monitorizar tudo por precaução" não é.
E se já estás a usar o Grafana, a integração com o Prometheus é a que vai fazer parecer uma ferramenta genuinamente útil em vez de um nice-to-have. Os dois foram desenhados para trabalhar juntos, e nota-se.
