Prometheus y Grafana: Checklist de Instalación y Alertas Críticas

Respuesta Directa

Un stack de monitoreo con Prometheus y Grafana permite recolectar, almacenar y visualizar métricas de sistema, configurando alertas personalizadas para prevenir caídas de servicio e identificar anomalías antes de que se conviertan en problemas críticos. La automatización del despliegue reduce a minutos los tiempos de configuración.

Snippet Rápido: Alerta de Disco Lleno

- alert: DiskSpaceCritical
  expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 5
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "Disco casi lleno en instancia {{ $labels.instance }}"
    description: "Espacio en disco inferior al 5% en {{ $labels.instance }} (filesystem {{ $labels.mountpoint }})"

Intro

Viernes por la noche. 23:45. Suena el teléfono. Servidor caído. Producción paralizada. ¿El problema? Disco lleno al 100%. Ninguna alerta se había disparado. Nadie sabía nada hasta que los usuarios empezaron a reportar la interrupción del servicio. ¿Lo irónico? El sistema de monitoreo estaba instalado en el mismo servidor que colapsó. Este escenario, lamentablemente, no es una excepción sino una realidad que he encontrado múltiples veces en entornos empresariales. Un stack de monitoreo bien diseñado y configurado no es un lujo, sino una necesidad para cualquier infraestructura moderna. En esta guía, veremos cómo implementar un sistema de monitoreo robusto con Prometheus y Grafana, centrándonos en la instalación, la configuración de alertas críticas y la automatización, para evitar que un simple disco lleno se convierta en una pesadilla nocturna.

Requisitos Previos / Entorno de Prueba

Para seguir esta guía, necesitarás:

• Un servidor Linux (Ubuntu 22.04 LTS o CentOS 8/9 Stream recomendado) con al menos 4GB de RAM y 2 núcleos de CPU para alojar Prometheus, Grafana y AlertManager.
• Al menos otro servidor Linux a monitorear (el ‘target’) con acceso SSH.
• Conocimientos básicos de Linux, systemd y conceptos de redes.
• Acceso sudo en ambos servidores.

Instalación Prometheus y Node Exporter

Prometheus es el corazón de nuestro sistema de monitoreo, responsable de la recolección de métricas. Node Exporter es un agente ligero que se ejecuta en los servidores target y expone métricas de hardware y del sistema operativo. Para garantizar la resiliencia, Prometheus y Node Exporter nunca deben residir en el mismo host monitoreado.

Instalación Node Exporter (en el servidor a monitorear)

En el servidor target, descargamos e instalamos Node Exporter. Utilizaremos la versión 1.8.0, estable y ampliamente probada.

# Descarga Node Exporter
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz

# Extrae el archivo
tar xvfz node_exporter-1.8.0.linux-amd64.tar.gz

# Mueve el binario a una ubicación accesible
sudo mv node_exporter-1.8.0.linux-amd64/node_exporter /usr/local/bin/

# Limpia los archivos descargados
rm -rf node_exporter-1.8.0.linux-amd64.tar.gz node_exporter-1.8.0.linux-amd64/

# Crea un usuario para Node Exporter
sudo useradd -rs /bin/false node_exporter

# Crea un archivo de servicio systemd para Node Exporter
sudo tee /etc/systemd/system/node_exporter.service > /dev/null <<EOF
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target
EOF

# Recarga systemd, habilita e inicia Node Exporter
sudo systemctl daemon-reload
sudo systemctl enable node_exporter
sudo systemctl start node_exporter

# Verifica el estado (debería ser 'active (running)')
sudo systemctl status node_exporter

# Verifica que las métricas estén expuestas (debería mostrar una página con métricas)
curl http://localhost:9100/metrics

Instalación Prometheus (en el servidor de monitoreo)

En el servidor dedicado al monitoreo, instalaremos Prometheus.

# Descarga Prometheus (versión más reciente, por ejemplo 2.44.0)
wget https://github.com/prometheus/prometheus/releases/download/v2.44.0/prometheus-2.44.0.linux-amd64.tar.gz

# Extrae el archivo
tar xvfz prometheus-2.44.0.linux-amd64.tar.gz

# Crea directorios y mueve los binarios
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo mv prometheus-2.44.0.linux-amd64/prometheus /usr/local/bin/
sudo mv prometheus-2.44.0.linux-amd64/promtool /usr/local/bin/
sudo cp -r prometheus-2.44.0.linux-amd64/{consoles,console_libraries} /etc/prometheus/

# Crea un usuario para Prometheus
sudo useradd -rs /bin/false prometheus

# Asigna permisos
sudo chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus
sudo chown prometheus:prometheus /usr/local/bin/prometheus /usr/local/bin/promtool

# Crea el archivo de configuración inicial (prometheus.yml)
sudo tee /etc/prometheus/prometheus.yml > /dev/null <<EOF
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['IP_DEL_SERVIDOR_A_MONITOREAR:9100'] # SUSTITUYE CON LA IP DE TU SERVIDOR TARGET
EOF

# Crea el archivo de servicio systemd para Prometheus
sudo tee /etc/systemd/system/prometheus.service > /dev/null <<EOF
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \n    --config.file /etc/prometheus/prometheus.yml \n    --storage.tsdb.path /var/lib/prometheus \n    --web.console.templates=/etc/prometheus/consoles \n    --web.console.libraries=/etc/prometheus/console_libraries \n    --web.listen-address=0.0.0.0:9090

[Install]
WantedBy=multi-user.target
EOF

# Recarga systemd, habilita e inicia Prometheus
sudo systemctl daemon-reload
sudo systemctl enable prometheus
sudo systemctl start prometheus

# Verifica el estado
sudo systemctl status prometheus

Accede a la interfaz web de Prometheus en http://IP_DEL_SERVIDOR_MONITORING:9090/targets para verificar que Node Exporter sea reconocido y las métricas se estén recolectando.

Grafana — datasource y dashboard Linux base

Grafana es la herramienta de visualización que usaremos para transformar las métricas de Prometheus en dashboards legibles y útiles.

Instalación Grafana

# Agrega la clave GPG de Grafana
sudo apt-get install -y apt-transport-https software-properties-common wget
wget -q -O - https://apt.grafana.com/gpg.key | sudo apt-key add -

# Agrega el repositorio Grafana
echo "deb https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update

# Instala Grafana
sudo apt-get install grafana

# Inicia y habilita Grafana
sudo systemctl daemon-reload
sudo systemctl enable grafana-server
sudo systemctl start grafana-server

# Verifica el estado
sudo systemctl status grafana-server

Accede a Grafana en http://IP_DEL_SERVIDOR_MONITORING:3000. Las credenciales por defecto son admin/admin (¡cámbialas inmediatamente!).

Configuración Datasource y Dashboard Linux Base

1. Agrega Datasource: En Grafana, ve a Configuration -> Data Sources -> Add data source. Selecciona Prometheus. En URL, introduce http://localhost:9090 (si Prometheus está en el mismo servidor) o la IP/hostname de Prometheus. Guarda y prueba.
2. Importa Dashboard: Los dashboards predefinidos son un excelente punto de partida. Busca en Grafana Labs los dashboards para Node Exporter (ID recomendado: 1860 para System Overview o 11074 para Node Exporter Full). Impórtalos a través de Dashboards -> Import e introduce el ID.

AlertManager — configurar notificaciones email y Telegram

AlertManager gestiona las alertas generadas por Prometheus, deduplicándolas, agrupándolas y enrutándolas a los receptores apropiados. Una alerta eficaz te permite actuar proactivamente.

Instalación AlertManager

# Descarga AlertManager (versión más reciente, por ejemplo 0.27.0)
wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz

# Extrae el archivo
tar xvfz alertmanager-0.27.0.linux-amd64.tar.gz

# Mueve el binario
sudo mv alertmanager-0.27.0.linux-amd64/alertmanager /usr/local/bin/
sudo mv alertmanager-0.27.0.linux-amd64/amtool /usr/local/bin/

# Crea directorios y usuario
sudo mkdir -p /etc/alertmanager /var/lib/alertmanager
sudo useradd -rs /bin/false alertmanager
sudo chown -R alertmanager:alertmanager /etc/alertmanager /var/lib/alertmanager
sudo chown alertmanager:alertmanager /usr/local/bin/alertmanager /usr/local/bin/amtool

# Configuración AlertManager (alertmanager.yml) - Ejemplo con email y Telegram
sudo tee /etc/alertmanager/alertmanager.yml > /dev/null <<EOF
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'default-receiver'

receivers:
  - name: 'default-receiver'
    email_configs:
      - to: '[email protected]'
        from: '[email protected]'
        smarthost: 'smtp.example.com:587'
        auth_username: 'smtp_user'
        auth_password: 'smtp_password'
    # Telegram (requiere un bot y un ID de chat - ver documentación de AlertManager)
    # telegram_configs:
    #   - bot_token: 'TU_BOT_TOKEN'
    #     chat_id: TU_CHAT_ID

EOF

# Crea el archivo de servicio systemd para AlertManager
sudo tee /etc/systemd/system/alertmanager.service > /dev/null <<EOF
[Unit]
Description=Prometheus Alertmanager
Wants=network-online.target
After=network-online.target

[Service]
User=alertmanager
Group=alertmanager
Type=simple
ExecStart=/usr/local/bin/alertmanager \n    --config.file /etc/alertmanager/alertmanager.yml \n    --storage.path /var/lib/alertmanager \n    --web.listen-address=0.0.0.0:9093

[Install]
WantedBy=multi-user.target
EOF

# Recarga systemd, habilita e inicia AlertManager
sudo systemctl daemon-reload
sudo systemctl enable alertmanager
sudo systemctl start alertmanager

# Verifica el estado
sudo systemctl status alertmanager

Configura Prometheus para enviar las alertas a AlertManager modificando prometheus.yml (agrega bajo global:):

alerting:
  alertmanagers:
  - static_configs:
    - targets: ['localhost:9093'] # O IP del AlertManager

Reinicia Prometheus para aplicar los cambios.

Alert rules críticas — disco, CPU, memoria, servicios down

Las reglas de alerta son la columna vertebral del monitoreo proactivo. Deben ser precisas para evitar la «fatiga de alertas», pero suficientemente sensibles para capturar los problemas a tiempo. Según un informe de IBM de 2024, el costo promedio de un downtime no planificado es de aproximadamente 9.000 dólares por minuto para las grandes empresas, y un buen sistema de alerting puede reducir significativamente esta cifra.

Crea un archivo rules.yml en /etc/prometheus/:

# /etc/prometheus/rules.yml

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: "Elevada carga de CPU en {{ $labels.instance }}"
      description: "La carga de CPU supera el 85% en {{ $labels.instance }} por más de 5 minutos."

  - alert: HighMemoryUsage
    expr: 100 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100) > 90
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Uso elevado de memoria en {{ $labels.instance }}"
      description: "La memoria utilizada supera el 90% en {{ $labels.instance }} por más de 5 minutos."

  - alert: DiskSpaceWarning
    expr: (node_filesystem_avail_bytes{fstype!="rootfs"} / node_filesystem_size_bytes{fstype!="rootfs"}) * 100 < 15
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Disco casi lleno en {{ $labels.instance }}"
      description: "Espacio en disco inferior al 15% en {{ $labels.instance }} (filesystem {{ $labels.mountpoint }})."

  - alert: DiskSpaceCritical
    expr: (node_filesystem_avail_bytes{fstype!="rootfs"} / node_filesystem_size_bytes{fstype!="rootfs"}) * 100 < 5
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Disco crítico en {{ $labels.instance }}"
      description: "Espacio en disco inferior al 5% en {{ $labels.instance }} (filesystem {{ $labels.mountpoint }})."

  - alert: ServiceDown
    expr: up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Servicio {{ $labels.job }} en {{ $labels.instance }} no alcanzable"
      description: "El target Prometheus {{ $labels.job }} en {{ $labels.instance }} ha fallado por más de 1 minuto."

Para incluir estas reglas en Prometheus, modifica prometheus.yml agregando la siguiente línea:

alerting:
  rule_files:
    - "/etc/prometheus/rules.yml"

Reinicia Prometheus para cargar las nuevas reglas. Puedes probar las reglas a través de la UI de Prometheus (/alerts).

Query de ejemplo: Memoria disponible

Para visualizar el porcentaje de memoria utilizada en Grafana o Prometheus:

100 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100)

Retention, storage y performance tuning

Prometheus archiva los datos localmente. Para entornos de producción con muchas métricas, es fundamental planificar el almacenamiento y la retención.

• Retention: La configuración por defecto es de 15 días. Puedes modificarla agregando --storage.tsdb.retention.time=30d (para 30 días) o --storage.tsdb.retention.size=50GB (para limitar el espacio) a los parámetros de inicio de Prometheus en el archivo prometheus.service.
• Performance: Para entornos muy grandes, considera el uso de soluciones de almacenamiento a largo plazo como Thanos o Mimir, que permiten escalabilidad horizontal y alta disponibilidad. Un análisis de 2023 de CNCF reveló que el 65% de las empresas que usan Prometheus en producción con más de 1000 hosts, adoptan una solución de almacenamiento a largo plazo. Más información en la documentación oficial de Prometheus.

Automatización con Ansible: stack completo en 10 minutos

La instalación manual es útil para entender los mecanismos, pero en producción la automatización es clave para la coherencia y la velocidad. He utilizado Ansible para automatizar el despliegue completo de Prometheus, Grafana y AlertManager. Esto me permite replicar la infraestructura de monitoreo entera en pocos minutos, reduciendo drásticamente los errores humanos y garantizando una configuración estandarizada en todos los servidores. Un playbook Ansible bien escrito puede instalar Node Exporter en decenas de servidores target y configurar el servidor de monitoreo con todas las dependencias, archivos de configuración y servicios systemd necesarios.

Errores Comunes y Resolución de Problemas

• Firewall: Asegúrate de que los puertos 9090 (Prometheus), 9100 (Node Exporter) y 3000 (Grafana) estén abiertos entre los servidores y para el acceso desde tu estación de trabajo.
• Permisos: Errores de permisos en los archivos de configuración o en los directorios de almacenamiento son frecuentes. Verifica que los usuarios prometheus y alertmanager tengan los permisos correctos (chown, chmod).
• Configuración YAML: Los errores de indentación en los archivos YAML son comunes. Usa promtool check config /etc/prometheus/prometheus.yml y amtool check-config /etc/alertmanager/alertmanager.yml para validar las configuraciones.
• Target Down: Si un target Node Exporter aparece como DOWN en Prometheus, verifica que el servicio node_exporter esté activo en el servidor target y que el firewall no bloquee el puerto 9100.

FAQ — Preguntas Frecuentes

¿Cómo puedo monitorear aplicaciones específicas (ej. Nginx, MySQL) con Prometheus?

Para monitorear aplicaciones específicas, puedes utilizar los «exporter» dedicados. Por ejemplo, existe un Nginx exporter, un MySQL exporter, etc. Estos funcionan de manera similar a Node Exporter, exponiendo métricas específicas de la aplicación que Prometheus puede recolectar. Los configuras como nuevos job en el archivo prometheus.yml.

¿Cuál es la diferencia entre for: 5m y group_wait: 30s en Prometheus/AlertManager?

for: 5m en una regla de alerta de Prometheus significa que la condición de la alerta debe ser verdadera durante al menos 5 minutos consecutivos antes de que la alerta se genere. group_wait: 30s en AlertManager es el tiempo que AlertManager espera después de recibir la primera alerta de un grupo antes de enviar las notificaciones, permitiendo agrupar alertas similares y enviar una única notificación.

¿Prometheus es adecuado para el monitoreo de logs?

No, Prometheus es un sistema orientado a las métricas (base de datos de series de tiempo) y no está optimizado para la recolección y análisis de logs. Para el monitoreo de logs, son más adecuados herramientas como ELK Stack (Elasticsearch, Logstash, Kibana), Grafana Loki o Splunk. Puedes integrar los logs con las métricas a través de Grafana.

¿Cómo puedo hacer que mi stack de monitoreo sea altamente disponible?

Para una alta disponibilidad, puedes configurar múltiples instancias de Prometheus en modo HA (High Availability) utilizando un sistema de almacenamiento a largo plazo compartido como Thanos o Mimir. AlertManager también puede configurarse en modo cluster. Grafana, al ser stateless, puede colocarse fácilmente detrás de un balanceador de carga.

Conclusiones con Puntos Clave Operativos

Implementar un stack de monitoreo eficaz con Prometheus y Grafana es un paso fundamental para la resiliencia de cualquier infraestructura IT. No se trata solo de recolectar datos, sino de transformarlos en insights accionables mediante alertas inteligentes. Recuerda:

1. Separar el monitoreo de lo monitoreado: Nunca instales el sistema de monitoreo en el mismo servidor que debe monitorear.
2. Configurar alertas críticas: Enfócate en disco, CPU, memoria y estado de los servicios como prioridad.
3. Automatizar el despliegue: Usa herramientas como Ansible para garantizar coherencia y escalabilidad.
4. Planificar el almacenamiento: La retención de datos es crucial para el análisis histórico y la resolución de problemas.

Un buen monitoreo te permite dormir más tranquilo y te permite intervenir antes de que un problema menor se convierta en una crisis de producción. El 92% de los profesionales de IT considera el monitoreo proactivo esencial para la continuidad operativa (SolarWinds, 2025).

Lee también

Lee también: Lynis Audit Linux: Guía Práctica de Hardening 2026

Lee también: LVM en Linux: Gestión Avanzada de Volúmenes Lógicos

Lee también: Netdata Linux: Monitoreo en Tiempo Real con Cero Configuración

Actualizado: junio 2026