Grafana: un origen de datos, el primer panel y una alerta que avisa al canal del equipo

Qué vas a conseguir

Un panel con el estado de los servidores (disco, CPU, memoria, servicios caídos) que se abre en la pantalla de la sala del equipo, y una alerta de "disco por encima del 85 %" que llega al canal de Teams con el nombre del servidor y el valor. Lo que se mide se arregla antes.

Antes de empezar

• El Grafana de la guía de Docker ya en marcha (o uno nuevo con el mismo Compose).
• Puerto 9100 abierto en los servidores hacia el servidor de herramientas (node_exporter) y 9090 solo en local.
• Un webhook entrante en el canal de Teams del equipo (Workflows → "Post to a channel when a webhook request is received"); la URL es un secreto.

1. Prometheus y node_exporter

Grafana pinta; alguien tiene que recoger. Añade Prometheus al Compose y el exportador a los servidores:

  prometheus:    image: prom/prometheus:v2.55.0    volumes:      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro      - prom-data:/prometheus    command: ["--config.file=/etc/prometheus/prometheus.yml", "--storage.tsdb.retention.time=90d"]    ports: ["127.0.0.1:9090:9090"]

global:  scrape_interval: 30sscrape_configs:  - job_name: linux    static_configs:      - targets:          - srv-web-01.contoso.local:9100          - srv-web-02.contoso.local:9100          - srv-db-01.contoso.local:9100        labels: { site: madrid }

›sudo useradd -rs /bin/false node_exporter›curl -sL https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz | sudo tar xz -C /usr/local/bin --strip-components=1 --wildcards '*/node_exporter'›sudo tee /etc/systemd/system/node_exporter.service >/dev/null <<'EOF'[Unit]Description=Prometheus Node ExporterAfter=network.target[Service]User=node_exporterExecStart=/usr/local/bin/node_exporter --collector.systemd[Install]WantedBy=multi-user.targetEOF›sudo systemctl enable --now node_exporter›sudo firewall-cmd --add-port=9100/tcp --permanent && sudo firewall-cmd --reload›curl -s localhost:9100/metrics | grep -E '^node_filesystem_avail_bytes.*mountpoint="/"'node_filesystem_avail_bytes{device="/dev/mapper/rhel-root",fstype="xfs",mountpoint="/"} 2.0401152e+10

En http://localhost:9090/targets (desde el servidor de herramientas, o por túnel SSH) los tres deben estar en UP. Si uno está en DOWN con connection refused, es el firewall del servidor; con context deadline exceeded, DNS o ruta.

2. El origen de datos y el primer panel

Tres paneles más y tienes el tablero del equipo: CPU 100 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100, memoria 100 * (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) y servicios caídos node_systemd_unit_state{state="failed"} == 1 como tabla. Guarda el dashboard y exporta su JSON al repo de Git: es la copia de seguridad.

Consejo: en lugar de inventar paneles, importa el 1860 (Node Exporter Full) desde Dashboards → New → Import. Es el tablero por servidor que usa medio mundo; el tuyo es la vista de flota.

3. El punto de contacto: Teams

Pulsa Test y mira el canal antes de seguir. Si no llega, el 95 % de las veces es la URL del webhook o que el flujo de Teams está desactivado.

4. La regla de alerta

El pending period de 10 minutos es lo que evita una alerta por un pico de un tar. La etiqueta severity y la Runbook URL (la página de Confluence del Nivel 2) son lo que convierte una notificación en algo accionable a las tres de la mañana. Comprueba que funciona bajando el umbral a 1 % un minuto y volviéndolo a subir.

5. Lo que revisas cada mes

• Alerting → Alert rules: reglas en estado Error o NoData (un servidor que ya no existe sigue en el inventario de Prometheus).
• Alertas que saltaron más de diez veces en el mes y nadie trató: o sobra la alerta o falta el arreglo.
• Retención de Prometheus frente al disco (du -sh del volumen prom-data).
• Exportar los dashboards cambiados al repo.

Siguientes pasos

• Windows: windows_exporter da lo mismo que node_exporter (disco, CPU, servicios); el mismo panel sirve con otro job_name.
• Añade Elasticsearch (guía de ELK) como origen de datos: la gráfica de errores por hora junto a la de CPU del mismo servidor.
• Grafana OnCall o la integración con la herramienta de guardia que uses para que las alertas severity=critical llamen por teléfono y las warning se queden en Teams.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.