Qual a diferença para o Uptime Kuma?

O Uptime Kuma responde «está no ar?». Prometheus e Grafana respondem «por que está lento, e desde quando?»: métricas de CPU, memória, disco, rede e aplicação ao longo do tempo. Muita gente usa os dois: o Kuma para alertas de queda, o Grafana para tendências e planejamento de capacidade.

Quanto disco o Prometheus usa?

Cerca de 1–2 bytes por amostra depois da compressão. Dez servidores exportando mil séries cada, coletadas a cada 15 segundos, dão uns 60 milhões de amostras por dia: na casa dos 100 MB. Com a retenção padrão de 15 dias, são alguns gigabytes.

Posso monitorar servidores em planos NAT?

Sim, mas não por coleta direta: um servidor NAT não aceita conexões de entrada no seu exporter. Rode o Prometheus em modo agent na máquina NAT e envie as métricas ao servidor de monitoramento com remote_write. O servidor de monitoramento em si deve estar num plano com IP dedicado.

Qual plano o servidor de monitoramento deve ter?

O Micro-IP (2 GB de RAM, $10/mês) dá conta com folga de uma ou duas dúzias de hosts. Se você adicionar métricas de aplicação com alta cardinalidade ou guardar meses de dados, passe para o Small-IP. Um IP dedicado dá HTTPS ao Grafana e um endereço estável para liberar nos seus alvos.

O servidor de monitoramento deve ser separado do que ele monitora?

Sim. Se o Grafana roda no servidor que acabou de ficar sem memória, você perde a visão do problema justo quando precisa dela. Um VPS pequeno e separado continua funcionando quando uma máquina de produção cai.

VPS para monitorar servidores com Grafana + Prometheus

Reúna num só lugar as métricas de CPU, RAM, disco e serviços de todos os seus servidores: Prometheus, node_exporter e Grafana num VPS, atrás de HTTPS.

«O servidor está lento» é um relato de bug inútil, a menos que você consiga abrir um gráfico e ver que a memória subiu por três dias antes da queda. É isso que Prometheus e Grafana oferecem: CPU, RAM, disco e rede de cada servidor, registrados a cada 15 segundos e desenhados em gráficos que você pode rolar para trás. Coloque-os num VPS pequeno só para eles e eles continuam observando mesmo quando uma máquina de produção cai.

As peças

node_exporter em cada servidor que você quer observar: expõe métricas do sistema na porta 9100.
Prometheus no VPS de monitoramento: coleta (scrape) essas métricas e as armazena.
Grafana: os painéis, atrás de HTTPS.
Opcionalmente Alertmanager ou os alertas do Grafana para avisar você quando algo passar de um limite.

Do que você precisa

Micro-IP ($10/mês, 2 vCPU, 2 GB de RAM, 25 GB) observa uma ou duas dúzias de servidores. Mais hosts, métricas de aplicação personalizadas ou meses de retenção: Small-IP.
Um IPv4 dedicado para o servidor de monitoramento: o Grafana é servido via HTTPS, e os seus alvos podem liberar um único endereço estável para a porta 9100.

1. node_exporter em cada alvo

apt install -y prometheus-node-exporter
# allow only the monitoring server to scrape it
ufw allow from 203.0.113.10 to any port 9100 proto tcp

Troque 203.0.113.10 pelo endereço do seu VPS de monitoramento. Nunca deixe a 9100 aberta para o mundo: ela revela muito sobre o seu servidor.

2. Prometheus e Grafana no VPS de monitoramento

apt update && apt install -y docker.io docker-compose-v2 caddy
mkdir -p /opt/monitoring && cd /opt/monitoring

cat > prometheus.yml <<'EOF'
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: nodes
    static_configs:
      - targets: ['198.51.100.21:9100', '198.51.100.22:9100']
EOF

cat > compose.yml <<'EOF'
services:
  prometheus:
    image: prom/prometheus
    volumes: [ "./prometheus.yml:/etc/prometheus/prometheus.yml:ro", "prom:/prometheus" ]
    command: [ "--config.file=/etc/prometheus/prometheus.yml", "--storage.tsdb.retention.time=15d", "--web.enable-remote-write-receiver" ]
    ports: [ "127.0.0.1:9090:9090" ]
    restart: unless-stopped
  grafana:
    image: grafana/grafana
    volumes: [ "grafana:/var/lib/grafana" ]
    ports: [ "127.0.0.1:3000:3000" ]
    restart: unless-stopped
volumes: { prom: {}, grafana: {} }
EOF

docker compose up -d

HTTPS na frente do Grafana:

echo 'grafana.example.com {
    reverse_proxy 127.0.0.1:3000
}' > /etc/caddy/Caddyfile && systemctl reload caddy

Entre (admin / admin, depois troque a senha), adicione o Prometheus como fonte de dados em http://prometheus:9090 e importe o painel da comunidade «Node Exporter Full» (ID 1860). Em cerca de um minuto você tem um painel de sistema completo.

Servidores em planos NAT

Um servidor NAT só aceita conexões de entrada na sua porta SSH pessoal, então o Prometheus não consegue coletar o exporter dele. Inverta a direção: rode o Prometheus em modo agent na máquina NAT e envie os dados ao servidor de monitoramento, que já aceita gravações remotas (a flag --web.enable-remote-write-receiver acima).

# /etc/prometheus/agent.yml on the NAT server
scrape_configs:
  - job_name: self
    static_configs: [ { targets: ['127.0.0.1:9100'] } ]
remote_write:
  - url: https://prom-push.example.com/api/v1/write

Exponha esse endpoint de envio pelo Caddy com basic auth em vez de abrir a porta 9090 diretamente.

Notas honestas

O Prometheus faz pull: ótimo para uma frota que você controla e incômodo para tudo que está atrás de NAT, daí o truque do agent. O armazenamento local dele não foi feito para anos de histórico; para retenção longa, você adicionaria um armazenamento remoto mais tarde. E os painéis são só metade do valor: configure pelo menos três alertas no primeiro dia (disco acima de 85%, pressão de memória, alvo fora do ar), ou você só vai olhar os gráficos depois que algo já tiver quebrado.

Relacionados

VPS para monitoramento de uptime (Uptime Kuma): alertas de queda e páginas de status
Como configurar o firewall UFW
Quanta RAM um VPS precisa?