Monitoramento de Infraestrutura com Grafana e Prometheus

Seu servidor caiu e você só descobriu quando o cliente ligou reclamando? Um disco encheu durante a madrugada e ninguém percebeu até o sistema parar de funcionar? Se isso já aconteceu na sua empresa, você tem um problema de monitoramento — ou melhor, de falta dele.

Downtime custa caro. Uma pesquisa da Gartner estimou que o custo médio de uma hora de inatividade para empresas é de US$ 5.600 — cerca de R$ 30.000 na cotação atual. Para e-commerces e empresas que dependem de sistemas online, esse valor pode ser ainda maior quando se soma a perda de vendas, dano à reputação e custo de recuperação.

A boa notícia é que montar um sistema de monitoramento profissional nunca foi tão acessível. Com Grafana e Prometheus — ambas ferramentas open-source — é possível ter dashboards em tempo real, alertas automáticos e visibilidade completa da infraestrutura por um custo que cabe no orçamento de qualquer PME.

Por que monitorar a infraestrutura

Monitoramento não é luxo de grandes empresas. Qualquer negócio que depende de servidores, aplicações web ou sistemas na nuvem precisa saber:

• O que está acontecendo agora: CPU, memória, disco, rede — em tempo real.
• O que está prestes a acontecer: tendências que indicam problemas futuros (disco enchendo, memória crescendo gradualmente, latência aumentando).
• O que aconteceu: histórico de métricas para diagnóstico de problemas passados e planejamento de capacidade.

Sem monitoramento, você opera no escuro. Com ele, você antecipa problemas antes que afetem o negócio.

Os benefícios práticos são:

• Redução de downtime: alertas proativos permitem agir antes do sistema cair. Empresas com monitoramento maduro reduzem o tempo médio de detecção de incidentes (MTTD) de horas para minutos.
• Planejamento de capacidade: dados históricos mostram quando será necessário expandir recursos, evitando tanto a subutilização (desperdício) quanto a falta de capacidade (problemas de performance).
• Diagnóstico rápido: quando algo dá errado, dashboards e logs facilitam a identificação da causa raiz. Em vez de "o sistema está lento", você sabe que "o servidor X está com 95% de uso de CPU por causa do processo Y".
• Conformidade e auditoria: registros de disponibilidade e performance são importantes para SLAs, contratos e auditorias.

Prometheus: o motor de coleta de métricas

O Prometheus é um sistema de monitoramento e alertas open-source, originalmente desenvolvido no SoundCloud e hoje graduado na Cloud Native Computing Foundation (CNCF). É o padrão de fato para monitoramento de infraestrutura moderna.

Como o Prometheus funciona

O modelo do Prometheus é pull-based: em vez de os sistemas enviarem métricas para ele, o Prometheus periodicamente consulta (scrape) endpoints HTTP que expõem métricas em um formato padronizado.

A arquitetura básica é:

1. Exporters: agentes que rodam nos sistemas monitorados e expõem métricas via HTTP. O mais comum é o Node Exporter, que coleta métricas do sistema operacional (CPU, memória, disco, rede).
2. Prometheus Server: coleta as métricas dos exporters em intervalos configuráveis (geralmente 15 ou 30 segundos) e armazena em um banco de dados de séries temporais.
3. PromQL: linguagem de consulta para analisar as métricas. Permite filtrar, agregar e calcular sobre os dados coletados.
4. AlertManager: componente que recebe alertas do Prometheus e os roteia para os canais configurados (e-mail, Slack, Telegram, WhatsApp, PagerDuty).

Métricas essenciais para monitorar

Nem tudo precisa ser monitorado. Foque nas métricas que realmente importam:

CPU:

• node_cpu_seconds_total: uso de CPU por core e por modo (user, system, idle, iowait).
• Alerta sugerido: uso médio acima de 85% por mais de 5 minutos.

Memória:

• node_memory_MemAvailable_bytes: memória disponível.
• Alerta sugerido: memória disponível abaixo de 15% por mais de 5 minutos.

Disco:

• node_filesystem_avail_bytes: espaço disponível em disco.
• node_disk_io_time_seconds_total: tempo de I/O do disco.
• Alerta sugerido: espaço em disco abaixo de 20% ou I/O wait acima de 30%.

Rede:

• node_network_receive_bytes_total / node_network_transmit_bytes_total: tráfego de rede.
• Alerta sugerido: tráfego anômalo (3x acima da média) pode indicar ataque ou problema.

Aplicação:

• Tempo de resposta (latência P95 e P99).
• Taxa de erro (5xx por minuto).
• Requisições por segundo (throughput).
• Alerta sugerido: latência P95 acima de 2 segundos ou taxa de erro acima de 1%.

Grafana: dashboards que fazem sentido

O Grafana é a ferramenta de visualização que transforma métricas brutas em dashboards compreensíveis. Conecta-se ao Prometheus (e dezenas de outras fontes de dados) e permite criar painéis customizados com gráficos, tabelas e indicadores.

Dashboards essenciais

Para começar, três dashboards cobrem as necessidades básicas:

1. Overview da infraestrutura: visão geral de todos os servidores com status (verde/amarelo/vermelho), uso de CPU, memória e disco. Permite identificar rapidamente qual servidor precisa de atenção.

2. Dashboard por servidor: detalhamento de um servidor específico com gráficos históricos de CPU, memória, disco, rede e processos. Útil para diagnóstico de problemas.

3. Dashboard de aplicação: métricas da aplicação (tempo de resposta, taxa de erro, throughput) que mostram a experiência do usuário final.

Templates prontos

O Grafana tem uma biblioteca de dashboards prontos que podem ser importados com um clique. Os mais populares:

• Node Exporter Full (ID: 1860): dashboard completo para servidores Linux com métricas do Node Exporter.
• Docker and System Monitoring (ID: 893): para ambientes com containers Docker.
• NGINX (ID: 9614): métricas específicas do servidor web NGINX.

Esses templates são um excelente ponto de partida. Você importa, ajusta para sua realidade e já tem visibilidade imediata.

Alertas inteligentes com AlertManager

Dashboards são úteis para análise, mas alertas são o que salvam sua operação às 3 da manhã. O AlertManager é o componente do Prometheus responsável por gerenciar alertas.

Configuração de alertas eficientes

A regra de ouro dos alertas é: alerte sobre sintomas, não causas. Ou seja, alerte quando algo afeta o usuário ou está prestes a afetar, não sobre cada flutuação de métrica.

Alertas mal configurados geram "alert fatigue" — a equipe recebe tantos alertas irrelevantes que passa a ignorar todos, incluindo os críticos. Para evitar isso:

• Defina severidades: Critical (precisa de ação imediata, acorda gente de madrugada), Warning (precisa de atenção no próximo horário comercial), Info (para registro e análise posterior).
• Use thresholds realistas: um servidor atingir 80% de CPU por 30 segundos não é alerta — pode ser um pico normal. Acima de 90% por 10 minutos é alerta.
• Agrupe alertas: se 5 servidores do mesmo cluster alertam ao mesmo tempo, mande uma notificação, não cinco.
• Defina horários de silêncio: durante janelas de manutenção, silencie alertas para evitar ruído.

Canais de notificação

O AlertManager pode enviar notificações para:

• E-mail: para alertas de baixa severidade.
• Slack/Discord: para alertas de média severidade, visíveis para toda a equipe.
• Telegram/WhatsApp: para alertas críticos que precisam de atenção imediata.
• PagerDuty/OpsGenie: para escalação automática e plantão rotativo.

Para empresas brasileiras, a integração com Telegram ou WhatsApp (via n8n) é a mais prática, já que são os apps de comunicação mais usados.

Monitorando containers Docker

Se sua empresa usa Docker (e se não usa, deveria considerar), o monitoramento de containers tem particularidades próprias.

cAdvisor

O cAdvisor (Container Advisor) é a ferramenta padrão para coletar métricas de containers Docker. Ele expõe métricas no formato Prometheus e monitora:

• Uso de CPU por container: quanto cada container consome.
• Uso de memória: incluindo limites configurados e uso real.
• I/O de disco e rede: por container.
• Status do container: running, stopped, restarting.

Métricas importantes para Docker

• Container restarts: um container que reinicia repetidamente indica um problema (crash loop).
• Uso vs limites: containers consumindo perto do limite de memória podem ser killed pelo OOM Killer a qualquer momento.
• Tempo de uptime: quanto tempo cada container está rodando.

Docker Compose para o stack de monitoramento

A forma mais prática de subir o stack completo de monitoramento é com Docker Compose. Um único arquivo define Prometheus, Grafana, Node Exporter, cAdvisor e AlertManager, todos configurados e conectados.

O custo de infraestrutura para o stack completo é mínimo: um servidor com 2 vCPU e 4GB de RAM (a partir de R$ 80/mês em provedores brasileiros) é suficiente para monitorar até 20 servidores com 30 dias de retenção de métricas.

Monitorando aplicações web

Além da infraestrutura, monitorar a aplicação em si é essencial para garantir a experiência do usuário.

Métricas RED

Para aplicações web, o padrão RED (Rate, Errors, Duration) é o mais adotado:

• Rate: quantas requisições por segundo a aplicação está recebendo.
• Errors: quantas requisições resultam em erro (4xx, 5xx).
• Duration: quanto tempo cada requisição leva para ser processada.

Instrumentação da aplicação

Para coletar métricas da aplicação, é necessário instrumentar o código. Bibliotecas como prom-client (Node.js), prometheus_client (Python) e micrometer (Java) permitem expor métricas customizadas no formato Prometheus.

Métricas úteis para instrumentar:

• Tempo de resposta por endpoint.
• Conexões ativas ao banco de dados.
• Tamanho da fila de processamento.
• Taxa de cache hit/miss.
• Erros por tipo e origem.

Uptime monitoring externo

Além do monitoramento interno, é fundamental monitorar de fora — da perspectiva do usuário. Ferramentas como UptimeRobot (gratuito para até 50 monitores), Uptime Kuma (open-source, self-hosted) e Pingdom verificam periodicamente se seus endpoints estão acessíveis e respondem dentro do tempo esperado.

Zabbix vs Prometheus: quando usar cada um

O Zabbix é outra ferramenta de monitoramento popular, especialmente em ambientes corporativos tradicionais. A comparação com o Prometheus é frequente.

| Aspecto | Prometheus | Zabbix | |---------|-----------|--------| | Modelo | Pull (scrape) | Push e Pull (agents) | | Armazenamento | TSDB próprio | PostgreSQL/MySQL | | Linguagem de consulta | PromQL (poderosa) | Triggers (simples) | | Visualização | Grafana (externo) | Interface própria | | Containers/Kubernetes | Nativo, excelente | Suporte limitado | | Agentes de rede | Limitado | Excelente (SNMP, IPMI) | | Curva de aprendizado | Moderada | Moderada a alta | | Comunidade | Muito ativa (cloud native) | Madura (enterprise) |

Quando escolher Prometheus: ambientes cloud native, containers, Kubernetes, microserviços, aplicações modernas. Se sua empresa está na nuvem ou planeja migrar, Prometheus é a escolha certa.

Quando escolher Zabbix: ambientes tradicionais com muitos dispositivos de rede (switches, roteadores, firewalls), servidores bare metal, necessidade de monitoramento SNMP nativo.

Para muitas empresas, a resposta é "ambos". Prometheus para aplicações e containers, Zabbix para infraestrutura de rede. Grafana conecta os dois e oferece uma visão unificada.

Como implementar na sua empresa

O caminho para implementar monitoramento profissional é gradual:

Semana 1 — Fundamentos:

• Instale Prometheus e Grafana (preferencialmente via Docker Compose).
• Configure Node Exporter em todos os servidores.
• Importe dashboards prontos para ter visibilidade imediata.

Semana 2 — Alertas:

• Configure AlertManager com canal de notificação (Telegram ou Slack).
• Defina alertas para as métricas mais críticas: disco cheio, CPU alta, memória baixa.
• Teste os alertas para garantir que funcionam.

Semana 3 — Aplicação:

• Instrumente suas aplicações com métricas customizadas.
• Crie dashboards específicos para cada aplicação.
• Configure uptime monitoring externo.

Semana 4 — Refinamento:

• Ajuste thresholds de alertas com base nos dados reais da primeira semana.
• Crie dashboards de overview para gestores.
• Documente a arquitetura e os runbooks (o que fazer quando cada alerta disparar).

O monitoramento é um investimento que se paga na primeira crise evitada. Um disco que não encheu, um servidor que não caiu, uma aplicação que não ficou lenta — cada incidente prevenido economiza horas de trabalho, receita perdida e desgaste com clientes.