Prometheus y Grafana: tu propio stack de monitoring en 2026

Qué hace Prometheus y por qué sigue siendo el estándar en 2026

Prometheus es un servidor de series temporales que pull-ea (scrapea) métricas de tus servicios y exporters en intervalos regulares. A diferencia de las soluciones push (statsd, InfluxDB), el modelo pull es más predecible: cuando un exporter cae, Prometheus se entera porque el scrape falla, no porque nadie le mande datos. Esto lo vuelve ideal para detectar caídas silenciosas sin configurar alertas en cada cliente.

En agosto de 2026 el proyecto va por la versión 3.14.0, con la rama 3.13 marcada como LTS hasta julio de 2027. La LTS es la elección correcta si tu stack es estable y no quieres migrar cada dos meses. Para servidores nuevos o setups en evolución andá directo a 3.14.

Qué hace Grafana y por qué lo complementás con Prometheus

Grafana es la capa de visualización. Prometheus sabe guardar series temporales y calcular reglas de alerting, pero su UI propia es funcional pero fea. Grafana toma la API de Prometheus y la convierte en dashboards navegables, alertas visuales, y un panel unificado donde puedes mezclar otras fuentes (Loki para logs, Tempo para traces, ClickHouse para analytics).

En 2026 vas a querer Grafana 12.0 como mínimo. Las versiones anteriores todavía funcionan pero vas a perder el Drilldown GA (Métricas, Logs, Traces unificados), que es la razón principal para actualizar si venís de 11.x.

Arquitectura mínima del stack

El stack clásico es:

• Prometheus: scrape, almacena series, evalúa reglas de alerta.
• node_exporter: corre en cada máquina Linux y expone métricas de CPU, memoria, disco, red, filesystem, kernel.
• Grafana: visualiza todo y dispara alertas visuales.
• Alertmanager (opcional pero recomendado): recibe las alertas de Prometheus y las enruta a Telegram, email, PagerDuty, etc.

Para una red de 5 a 20 servidores Linux este stack corre perfectamente en una sola VM con 2 vCPUs y 4 GB de RAM. Prometheus consume poca CPU pero la base de datos local (su propio TSDB) crece con la retención, así que dimensioná disco con margen.

Instalación de Prometheus 3.14 sobre Debian 13

El método recomendado en producción es descargar el binario oficial y correrlo como servicio systemd. No uses el paquete prometheus de los repos de Debian — viene con una versión vieja y se actualiza con meses de delay.

# Crear usuario y directorios
sudo useradd --system --no-create-home --shell /usr/sbin/nologin prometheus
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus
# Descargar Prometheus 3.14.0 (verificar SHA256 contra prometheus.io/download)
cd /tmp
curl -sLO https://github.com/prometheus/prometheus/releases/download/v3.14.0/prometheus-3.14.0.linux-amd64.tar.gz
echo "f665c6da19eb7ba399c915d30c7d9793c9b417bf8a749b504bc470678631478d  prometheus-3.14.0.linux-amd64.tar.gz" | sha256sum -c -
# Extraer binarios
tar xzf prometheus-3.14.0.linux-amd64.tar.gz
sudo cp prometheus-3.14.0.linux-amd64/prometheus /usr/local/bin/
sudo cp prometheus-3.14.0.linux-amd64/promtool /usr/local/bin/
sudo chmod +x /usr/local/bin/prometheus /usr/local/bin/promtool
sudo chown prometheus:prometheus /usr/local/bin/prometheus /usr/local/bin/promtool

El paso de verificar SHA256 es importante porque el binario corre con privilegios de sistema. Si la suma no coincide, NO lo instales. promtool te sirve después para validar archivos de configuración antes de reiniciar Prometheus.

Configuración inicial de Prometheus

El archivo principal es /etc/prometheus/prometheus.yml. Para empezar necesitas declarar tus targets de scrape y la frecuencia. La configuración mínima funcional para monitorear el propio servidor Prometheus más un node_exporter local:

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    monitor: 'homelab-prometheus'
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']
rule_files:
  - "alerts.yml"
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

Para más servidores vas a reemplazar localhost:9100 por IPs reales o usar file_sd_configs / Consul para discovery automático. El intervalo de 15s es el default; bajalo a 5s si necesitas alta resolución, subilo a 30s o 60s si te importa más la retención que la precisión.

Crear el servicio systemd

Prometheus necesita correr como demonio y reiniciarse si se cae. Sin systemd unit propio vas a terminar lanzándolo en una sesión SSH que se cierra y matando el proceso sin querer.

cat | sudo tee /etc/systemd/system/prometheus.service > /dev/null <<'EOF'
[Unit]
Description=Prometheus monitoring system
Documentation=https://prometheus.io/docs/
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=prometheus
Group=prometheus
ExecStart=/usr/local/bin/prometheus 
  --config.file=/etc/prometheus/prometheus.yml 
  --storage.tsdb.path=/var/lib/prometheus 
  --storage.tsdb.retention.time=30d 
  --web.console.libraries=/usr/share/prometheus/console_libraries 
  --web.enable-lifecycle
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now prometheus
sudo systemctl status prometheus

El flag --web.enable-lifecycle te permite recargar la configuración con curl -X POST http://localhost:9090/-/reload sin reiniciar el proceso. Útil cuando agregás targets o reglas nuevas. La retención de 30 días (--storage.tsdb.retention.time) es un balance razonable para un homelab; en producción ajustá según tu capacidad de disco.

Instalación de node_exporter 1.12 en cada servidor a monitorear

node_exporter es el agente que expone métricas del sistema. Corre como proceso aislado en cada máquina que quieres observar y escucha en el puerto 9100.

cd /tmp
curl -sLO https://github.com/prometheus/node_exporter/releases/download/v1.12.0/node_exporter-1.12.0.linux-amd64.tar.gz
tar xzf node_exporter-1.12.0.linux-amd64.tar.gz
sudo cp node_exporter-1.12.0.linux-amd64/node_exporter /usr/local/bin/
sudo useradd --system --no-create-home --shell /usr/sbin/nologin node_exporter
cat | sudo tee /etc/systemd/system/node_exporter.service > /dev/null <<'EOF'
[Unit]
Description=Prometheus node_exporter
After=network-online.target
[Service]
Type=simple
User=node_exporter
Group=node_exporter
ExecStart=/usr/local/bin/node_exporter 
  --collector.filesystem.mount-points-exclude='^/(sys|proc|dev|host|etc)($$|/)'
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter
sudo systemctl status node_exporter

El exclude de mountpoints es para que no te aparezcan falsos positivos de espacio en disco en /proc, /sys y /dev (que son filesystems virtuales y nunca se llenan). Sin ese flag vas a tener dashboards mostrando “disco lleno” que no es real.

Después de instalar, agregá la IP de este servidor como target en el Prometheus central. Si la máquina nueva es 10.0.0.50, el bloque scrape_configs en el server Prometheus queda:

  - job_name: 'node'
    static_configs:
      - targets:
        - 'localhost:9100'
        - '10.0.0.50:9100'
        - '10.0.0.51:9100'

Instalación de Grafana 12 sobre Debian

Grafana tiene repositorio APT oficial. Es la forma más limpia de mantenerlo actualizado.

sudo apt-get install -y apt-transport-https software-properties-common
sudo mkdir -p /etc/apt/keyrings/
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install -y grafana
sudo systemctl enable --now grafana-server
sudo systemctl status grafana-server

Después de instalar, Grafana escucha en http://localhost:3000. El usuario default es admin con contraseña admin; el primer login te obliga a cambiarla. configura un reverse proxy con HTTPS antes de exponerlo a internet — Grafana no trae TLS integrado y mandar credenciales en plano es buscar problemas.

Conectar Grafana a Prometheus como datasource

Una vez que Prometheus y Grafana estén corriendo, agregá Prometheus como fuente de datos en Grafana. Desde la UI: Configuration → Data sources → Add data source → Prometheus. La URL es http://localhost:9090 si están en el mismo servidor, o la IP/puerto de Prometheus si están separados.

activa el toggle “Default” para que sea la fuente por defecto al crear paneles. El scrape interval acá es solo el default para nuevos paneles; cada panel puede sobreescribirlo.

Importar el dashboard oficial de node_exporter

El dashboard “Node Exporter Full” (ID 1860 en grafana.com) es el punto de partida estándar para monitorear Linux. Tiene paneles para CPU, memoria, disco, red, presión de memoria (PSI), carga, y filesystem. Importarlo es trivial desde la UI:

1. En Grafana: Dashboards → New → Import.
2. Pegá el ID 1860 en el campo “Import via grafana.com”.
3. Seleccioná tu datasource Prometheus.
4. Click Import.

Si tienes varios servidores, Grafana puede filtrar por label instance usando la variable $instance que el dashboard trae preconfigurada. Seleccionás qué servidor ver desde el dropdown arriba.

Alertas accionables (reglas en Prometheus)

Una métrica sin alerta es solo un número bonito. Las reglas viven en /etc/prometheus/alerts.yml y Prometheus las evalúa cada evaluation_interval (15s por default).

groups:
- name: host_alerts
  rules:
  - alert: HighCpuLoad
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "CPU alta en {{ $labels.instance }}"
      description: "CPU arriba de 85% por 5 min en {{ $labels.instance }}"
  - alert: DiskSpaceLow
    expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) * 100 < 10
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "Disco casi lleno en {{ $labels.instance }}"
  - alert: HostDown
    expr: up == 0
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.instance }} no responde a scrapes"

Recargá Prometheus después de tocar alerts.yml:

promtool check rules /etc/prometheus/alerts.yml
curl -X POST http://localhost:9090/-/reload

El promtool check rules es crítico: si la regla tiene un error de sintaxis Prometheus la ignora silenciosamente. Sin validación previa vas a creer que la alerta está armada y no enterarte hasta que el servidor se caiga.

Alertmanager y notificaciones

Las alertas que dispara Prometheus se mandan a Alertmanager (puerto 9093 por default). Alertmanager deduplica, agrupa y enruta a destinos externos (Telegram, Slack, email, PagerDuty).

Configuración mínima funcional para mandar a Telegram:

route:
  receiver: 'telegram-default'
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
receivers:
- name: 'telegram-default'
  telegram_configs:
  - bot_token: '<TU_BOT_TOKEN>'
    chat_id: <TU_CHAT_ID>
    parse_mode: 'HTML'
    message: |
      <b>{{ .GroupLabels.alertname }}</b>
      {{ range .Alerts }}
      <b>Instance</b>: {{ .Labels.instance }}
      <b>Severity</b>: {{ .Labels.severity }}
      {{ end }}

El group_wait de 30s evita que se manden 15 alertas duplicadas si un servidor se cae y dispara todas sus reglas a la vez. repeat_interval de 4h es para que no te llegue spam si la condición persiste.

Cuándo NO usar Prometheus

Prometheus está optimizado para series temporales de métricas con cardinalidad moderada. Si tu caso es:

• Logs centralizados: usa Loki + Promtail (mismo ecosistema).
• Traces distribuidos: Tempo o Jaeger.
• Eventos con cardinalidad altísima (millones de dimensiones únicas): Prometheus se queda corto. mira ClickHouse, TimescaleDB o Honeycomb.
• Retención mayor a 6 meses en producción seria: vas a necesitar Thanos o Cortex para federar storages.

Para el 95% de setups de sysadmin Linux (10-50 servidores, métricas de sistema, retención 30-90 días) Prometheus es exactamente la herramienta correcta.

Resumen

El stack mínimo que necesitas:

• Prometheus 3.14 (o 3.13 LTS si priorizás estabilidad) en un servidor central.
• node_exporter 1.12 en cada máquina a monitorear.
• Grafana 12 con el dashboard 1860 importado.
• Alertmanager conectado a tu canal de notificaciones.

Con esto tienes visibilidad real de CPU, memoria, disco, red, carga y presión de memoria en todos tus servidores, con alertas que te avisan antes de que algo se caiga. La curva de aprendizaje es una tarde de setup; el retorno operativo aparece la primera vez que detectás un disco llenándose a las 3am en vez de enterarte cuando el servicio falla.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux