¿En qué se diferencia de Uptime Kuma?

Uptime Kuma responde a «¿está funcionando?». Prometheus y Grafana responden a «¿por qué va lento y desde cuándo?»: CPU, memoria, disco, red y métricas de aplicación a lo largo del tiempo. Mucha gente usa ambos: Kuma para alertas de caída y Grafana para tendencias y planificación de capacidad.

¿Cuánto disco usa Prometheus?

Aproximadamente 1–2 bytes por muestra tras la compresión. Diez servidores que exportan mil series cada uno, recogidas cada 15 segundos, suman unos 60 millones de muestras al día, del orden de 100 MB. Con la retención por defecto de 15 días, son un par de gigabytes.

¿Puedo monitorizar servidores con plan NAT?

Sí, pero no por scraping: un servidor NAT no acepta conexiones entrantes a su exporter. Ejecuta Prometheus en modo agente en la máquina NAT y envía las métricas a tu servidor de monitorización con remote_write. El servidor de monitorización, en cambio, debe estar en un plan con IP dedicada.

¿Qué plan para el servidor de monitorización?

Un Micro-IP (2 GB de RAM, $10/mes) vigila cómodamente una o dos docenas de equipos. Si añades métricas de aplicación de alta cardinalidad o guardas meses de datos, pasa a Small-IP. Una IP dedicada te da HTTPS para Grafana y una dirección estable para permitir en tus objetivos.

¿El servidor de monitorización debe estar separado de lo que vigila?

Sí. Si Grafana corre en el servidor que se acaba de quedar sin memoria, pierdes la vista del problema justo cuando la necesitas. Un VPS pequeño y separado sigue funcionando cuando un servidor de producción cae.

VPS para Grafana + Prometheus: monitorizar servidores

Reúne CPU, RAM, disco y métricas de servicios de todos tus servidores en un solo lugar: Prometheus, node_exporter y Grafana en un VPS, detrás de HTTPS.

«El servidor va lento» es un informe de error inútil, salvo que puedas abrir una gráfica y ver que la memoria subió durante tres días antes del fallo. Eso es exactamente lo que dan Prometheus y Grafana: la CPU, la RAM, el disco y la red de cada servidor, registrados cada 15 segundos y dibujados en gráficas por las que puedes retroceder. Ponlos en su propio VPS pequeño y seguirán vigilando aunque caiga una máquina de producción.

Las piezas

node_exporter en cada servidor que quieras vigilar: expone las métricas del sistema en el puerto 9100.
Prometheus en el VPS de monitorización: recoge (scrapea) esas métricas y las guarda.
Grafana: los paneles, detrás de HTTPS.
Opcionalmente, Alertmanager o las alertas de Grafana para avisarte cuando algo cruce un umbral.

Qué necesitas

Micro-IP ($10/mes, 2 vCPU, 2 GB de RAM, 25 GB) vigila una o dos docenas de servidores. Más equipos, métricas propias de aplicación o meses de retención: Small-IP.
Una IPv4 dedicada para el servidor de monitorización: Grafana se sirve por HTTPS, y tus objetivos pueden permitir una sola dirección estable en el puerto 9100.

1. node_exporter en cada objetivo

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

Sustituye 203.0.113.10 por la dirección de tu VPS de monitorización. Nunca dejes el 9100 abierto a todo el mundo: revela mucho sobre tu servidor.

2. Prometheus y Grafana en el VPS de monitorización

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 delante de Grafana:

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

Inicia sesión (admin / admin, y luego cámbiala), añade Prometheus como fuente de datos en http://prometheus:9090 e importa el panel de la comunidad «Node Exporter Full» (ID 1860). Tendrás un panel completo del sistema en un minuto aproximadamente.

Servidores con plan NAT

Un servidor NAT solo acepta conexiones entrantes en su puerto SSH personal, así que Prometheus no puede consultar su exporter. Invierte el sentido: ejecuta Prometheus en modo agente en la máquina NAT y envía los datos al servidor de monitorización, que ya acepta escrituras remotas (la opción --web.enable-remote-write-receiver de arriba).

# /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

Expón ese punto de recepción a través de Caddy con autenticación básica en lugar de abrir el puerto 9090 tal cual.

Notas honestas

Prometheus va a buscar los datos él mismo: ideal para una flota que controlas, incómodo para todo lo que está detrás de NAT, de ahí el truco del agente. Su almacenamiento local no está pensado para años de historial; para una retención larga, más adelante se añade un almacenamiento remoto. Y los paneles son solo la mitad del valor: configura al menos tres alertas el primer día (disco por encima del 85 %, presión de memoria, objetivo caído), o solo mirarás las gráficas cuando algo ya se haya roto.

Relacionado

VPS para monitorizar la disponibilidad (Uptime Kuma): alertas de caída y páginas de estado
Cómo configurar un cortafuegos UFW
¿Cuánta RAM necesita un VPS?