Monitorización: Parte 3 — Prometheus, Node Exporter y Grafana

Prometheus — sistema de monitorización y base de datos de series temporales de código abierto (licencia Apache 2.0). Fue creado en la empresa SoundCloud en 2012, y en 2016 el proyecto entró en la Cloud Native Computing Foundation en segundo lugar después de Kubernetes. La versión 3.0 se publicó en noviembre de 2024; a septiembre de 2026 la vigente es la 3.14, y la 3.13 fue declarada lanzamiento con soporte a largo plazo (LTS).

Prometheus suele utilizarse junto con Node Exporter, que exporta métricas del servidor Linux, Alertmanager, que envía alertas, y Grafana, donde se construyen los paneles.

Cómo funciona Prometheus

La característica principal es el modelo pull: Prometheus consulta por HTTP a los targets con un intervalo definido y recoge las métricas en formato de texto. Cada métrica es un nombre y un conjunto de etiquetas, por ejemplo node_cpu_seconds_total{cpu="0",mode="idle"}. Las etiquetas permiten filtrar y agrupar datos en las consultas.

Componentes del ecosistema:

• Prometheus Server — recoge métricas, las almacena en disco local, ejecuta consultas en el lenguaje PromQL y evalúa reglas de alerta.
• Exportadores — programas que traducen los datos del sistema al formato Prometheus: node_exporter para servidores, postgres_exporter y mysqld_exporter para bases de datos, blackbox_exporter para comprobar sitios y puertos desde el exterior.
• Alertmanager — recibe las alertas activadas, las agrupa, suprime repeticiones y las envía a Telegram, por correo o a un servicio de guardia.
• Pushgateway — un intermediario para tareas cortas, por ejemplo copias de seguridad nocturnas, que terminan antes de que Prometheus tenga tiempo de consultarlas.

Instalación mínima

Node Exporter se ejecuta en cada servidor; por defecto expone métricas en el puerto 9100. El propio Prometheus lee la configuración desde prometheus.yml:

global:
  scrape_interval: 30s
  evaluation_interval: 30s

rule_files:
  - /etc/prometheus/rules/*.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["localhost:9093"]

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: node
    static_configs:
      - targets:
          - "192.0.2.21:9100"
          - "192.0.2.22:9100"

El puerto 9100 debe ser accesible solo desde el servidor Prometheus: las métricas revelan mucho sobre el estado del sistema.

Regla de alerta

Las reglas se almacenan en archivos separados. Ejemplo de dos reglas típicas: el servidor no responde y el disco se está quedando sin espacio:

groups:
  - name: node
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} no responde desde hace 5 minutos"

      - alert: DiskSpaceLow
        expr: |
          node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}
            / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"} < 0.10
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }}: menos del 10 % libre en {{ $labels.mountpoint }}"

El parámetro for indica cuánto tiempo debe mantenerse la condición antes de dispararse, —esto descarta picos breves. El archivo de reglas se verifica antes de aplicarlo con el comando promtool check rules.

Enrutamiento en Alertmanager

Alertmanager decide a quién y cómo enviar la alerta. Las críticas van inmediatamente a Telegram; las demás, al correo con agrupamiento:

route:
  receiver: email
  group_by: ["alertname", "instance"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - receiver: telegram
      matchers:
        - severity="critical"
      group_wait: 10s

receivers:
  - name: email
    email_configs:
      - to: "admin@example.ru"
  - name: telegram
    telegram_configs:
      - bot_token: "TOKEN_DEL_BOT"
        chat_id: 123456789

Para el envío de correo, en el bloque global se especifica además el servidor SMTP (smtp_smarthost, smtp_from y las credenciales).

Grafana

Prometheus tiene una interfaz simple integrada para consultas, pero los paneles se construyen en Grafana. Esta conecta Prometheus como origen de datos, soporta decenas de otras fuentes y permite crear paneles interactivos con variables y alertas. Para Node Exporter hay paneles listos en el catálogo de Grafana, que se importan por número.

Desde abril de 2021 Grafana se distribuye bajo la licencia AGPLv3 (antes — Apache 2.0). Para uso interno eso no cambia nada, pero si modifica el código de Grafana y la ofrece como servicio a otros, tendrá que publicar los cambios.

Ventajas

• PromQL. Lenguaje de consulta flexible: tasas de cambio, percentiles, agregación por etiquetas.
• Exportadores para casi todo. Bases de datos, servidores web, colas, equipamiento de red vía SNMP.
• Descubrimiento de targets. Prometheus encuentra targets por sí mismo en Kubernetes, Consul, nubes y mediante DNS.
• Alertas maduras. Alertmanager sabe agrupar, suprimir y enrutar notificaciones.
• Reglas de grabación. Consultas costosas se pueden calcular por adelantado y guardar como nuevas métricas.

Desventajas

• Barreras de entrada. Hay que aprender la configuración, PromQL y el diseño de etiquetas.
• Almacenamiento local. Por defecto los datos se guardan 15 días en el disco de un único servidor. Para retención a largo plazo y múltiples servidores se usan almacenamientos externos: VictoriaMetrics, Thanos, Mimir.
• Modelo pull. Es difícil escrutar targets detrás de NAT o en redes aisladas; se recurre a agentes que envían datos (remote write) o a Pushgateway.
• Alta cardinalidad. Etiquetas con valores únicos —identificadores de usuarios, URLs completas— aumentan drásticamente el número de series y el uso de memoria.

Errores típicos

• Valores únicos en etiquetas. La causa principal de saturación de memoria. En las etiquetas solo debe ponerse lo que realmente se agrupa.
• No usar el for. Las alertas se disparan por cada pico de un segundo.
• Monitorizar sin comprobar el propio monitor. Si Prometheus cae, no habrá alertas. Hace falta una comprobación externa de disponibilidad o una segunda instancia.
• Exportadores expuestos a Internet. El puerto 9100 sin restricción de acceso revela versiones, particiones de disco e interfaces de red.