↓ Ir al contenido
Homelab.es
  1. Posts/

Monitorización con Grafana y Prometheus: mi setup real en el homelab

·2328 palabras·11 mins
homelab Grafana Prometheus Monitoring Docker Alertas
Tabla de contenido

Llevo un año con Grafana y Prometheus corriendo en mi homelab y es probablemente una de las cosas que más uso a diario. No porque sea bonito (que lo es), sino porque me he ahorrado un montón de problemas al ver las cosas antes de que exploten.

Te cuento cómo lo tengo montado, qué métricas vigilo, y sobre todo, los errores que cometí para que tú no los repitas.

Por qué necesitas monitorización en tu homelab
#

Mira, cuando empecé con el homelab solo tenía un mini PC con Docker. Sabía si algo iba mal porque dejaba de funcionar. Directo, efectivo, cero métricas.

Luego monté un cluster Proxmox de 3 nodos. Después añadí el NAS. Luego más contenedores. En algún momento perdí la cuenta de cuántos servicios estaban corriendo.

Y ahí es cuando las cosas se complican. Recibes un aviso de WhatsApp de que “el Plex no va”, pero no sabes si es la red, el disco duro, la CPU, la RAM, o simplemente que tu ISP decidió hacer mantenimiento sin avisar.

Sin métricas, debuggear es adivinar con suerte.

Qué es Prometheus y por qué no Zabbix
#

Prometheus es un sistema de monitorización diseñado para entornos cloud-native. Guarda métricas como series temporales y tiene su propio lenguaje de queries (PromQL) que al principio asusta pero luego se vuelve adictivo.

Lo elegí sobre Zabbix o Nagios porque:

  • Se integra de forma nativa con Docker y Kubernetes
  • Los exporters son fáciles de configurar
  • La comunidad es brutal (hay dashboards para todo)
  • Es lo que usa la gente que hace esto profesionalmente

Zabbix es potente pero se siente de otra época. Nagios directamente me da flashbacks de 2010. Si estás empezando ahora, Prometheus es la opción.

Grafana: el frontend que hace que las métricas importen
#

Prometheus guarda las métricas, pero Grafana es donde las ves. Paneles, gráficas, alertas visuales, todo en dashboards que puedes customizar hasta el infinito.

La primera vez que vi un dashboard de Grafana bien montado fue una revelación. Números que se actualizan en tiempo real, colores que cambian cuando algo va mal, gráficas que muestran tendencias en lugar de solo “esto está al 80%”.

Es lo más parecido a tener un centro de control de la NASA en tu homelab.

Mi stack de monitorización
#

Actualmente tengo esto corriendo:

  • Prometheus (servidor principal, scraping cada 15 segundos)
  • Grafana (dashboards y alertas)
  • Node Exporter (métricas de host en cada nodo)
  • cAdvisor (métricas de contenedores Docker)
  • Blackbox Exporter (checks HTTP/ICMP)
  • Alertmanager (gestión de alertas hacia Telegram)

Todo corre en Docker Compose en mi nodo principal de Proxmox. Tengo un volumen dedicado para las métricas históricas porque Prometheus puede comer bastante espacio si no lo limitas.

Docker Compose: mi configuración real
#

Este es el docker-compose.yml que uso. Lo pongo completo porque odio los tutoriales que te dan solo fragmentos y luego tienes que adivinar el resto.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: unless-stopped
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=90d'
      - '--web.console.libraries=/usr/share/prometheus/console_libraries'
      - '--web.console.templates=/usr/share/prometheus/consoles'
    ports:
      - "9090:9090"
    networks:
      - monitoring

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: unless-stopped
    volumes:
      - grafana-data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=cambiar_esto
      - GF_USERS_ALLOW_SIGN_UP=false
      - GF_SERVER_ROOT_URL=https://grafana.midominio.com
      - GF_INSTALL_PLUGINS=grafana-clock-panel,grafana-piechart-panel
    ports:
      - "3000:3000"
    networks:
      - monitoring

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    restart: unless-stopped
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--path.rootfs=/host'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/host:ro
    ports:
      - "9100:9100"
    networks:
      - monitoring

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    restart: unless-stopped
    privileged: true
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    ports:
      - "8080:8080"
    networks:
      - monitoring

  blackbox-exporter:
    image: prom/blackbox-exporter:latest
    container_name: blackbox-exporter
    restart: unless-stopped
    volumes:
      - ./blackbox/blackbox.yml:/etc/blackbox_exporter/config.yml
    ports:
      - "9115:9115"
    networks:
      - monitoring

networks:
  monitoring:
    driver: bridge

volumes:
  prometheus-data:
  grafana-data:

Nota importante: storage.tsdb.retention.time=90d limita las métricas a 90 días. Sin esto, Prometheus crece sin control. He visto instancias de gente con 500GB de métricas porque no pusieron límite.

Configuración de Prometheus
#

El archivo prometheus.yml define qué scraper y con qué frecuencia. Este es el mío:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    cluster: 'homelab'
    datacenter: 'casa'

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

  - job_name: 'node-exporter'
    static_configs:
      - targets: 
        - '192.168.1.10:9100'  # Nodo 1
        - '192.168.1.11:9100'  # Nodo 2
        - '192.168.1.12:9100'  # Nodo 3
        - '192.168.1.15:9100'  # NAS

  - job_name: 'cadvisor'
    static_configs:
      - targets:
        - '192.168.1.10:8080'
        - '192.168.1.11:8080'
        - '192.168.1.12:8080'

  - job_name: 'blackbox-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - https://plex.midominio.com
        - https://nextcloud.midominio.com
        - https://vaultwarden.midominio.com
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

Fíjate en los external_labels. No son obligatorios, pero si algún día montas Grafana Cloud o Thanos para federación, te va a salvar la vida tener las métricas etiquetadas por origen.

Métricas que realmente importan
#

Prometheus puede sacar métricas de todo. CPU, RAM, disco, red, temperatura, procesos, sockets abiertos, lo que sea. El problema es que si vigilas todo, no vigilas nada.

Estas son las métricas que yo miro de verdad:

CPU y carga del sistema
#

1

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Esto te da el porcentaje de CPU en uso. Si pasa del 80% sostenido, algo raro está pasando.

Memoria disponible
#

1

(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

Cuando baja del 10%, el sistema empieza a hacer swap y todo se ralentiza. Prefiero saber antes de que pase.

Disco: espacio y I/O
#

1

100 - ((node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100)

Los discos llenos son el enemigo silencioso del homelab. Un log que crece sin control y de repente todo deja de funcionar.

Temperatura (si tu hardware lo soporta)
#

1

node_hwmon_temp_celsius

En verano, cuando el despacho se convierte en un horno, esta métrica me ha salvado más de un disco duro.

Uptime de servicios (vía Blackbox)
#

1

probe_success{job="blackbox-http"}

Si devuelve 0, el servicio no responde. Simple y efectivo.

Dashboards: importar o crear desde cero
#

Grafana tiene miles de dashboards públicos en grafana.com/dashboards. Puedes importar uno por ID y tenerlo funcionando en 30 segundos.

Los que uso:

  • Node Exporter Full (ID: 1860) - el clásico, métricas de host completas
  • Docker Container & Host Metrics (ID: 179) - para ver qué contenedores comen recursos
  • Blackbox Exporter (ID: 7587) - uptime de servicios HTTP

Pero también he hecho dashboards propios para cosas específicas. Por ejemplo, tengo uno que solo muestra las métricas del cluster Proxmox: CPU total, RAM total, almacenamiento Ceph, VMs corriendo.

Crear dashboards desde cero es fácil una vez le pillas el truco a PromQL. Arrastras un panel, escribes la query, eliges el tipo de gráfica (línea, barra, gauge) y listo.

Alertas: que Telegram te avise cuando algo va mal
#

Las métricas bonitas están bien, pero si tienes que mirar Grafana cada hora para ver si todo va bien, has fracasado. Las alertas son lo que convierte la monitorización en algo útil de verdad.

Grafana tiene un sistema de alertas integrado. Defines condiciones (CPU > 90% durante 5 minutos, disco > 85%, servicio caído) y envía notificaciones cuando se cumplen.

Yo uso Telegram como canal de alertas. Es instantáneo, no depende de email, y puedo responder desde el móvil estés donde esté.

Configurar notificaciones en Telegram
#

  1. Crea un bot con @BotFather
  2. Consigue tu Chat ID (habla con @userinfobot)
  3. En Grafana: Alerting → Contact points → New contact point
  4. Tipo: Telegram
  5. BOT API Token: el token que te dio BotFather
  6. Chat ID: tu ID personal o de grupo

Hecho. Ahora cada alerta que se dispare te llegará a Telegram.

Mis reglas de alerta
#

No pongo alertas por todo. Si te llegan 50 notificaciones al día, dejas de hacerles caso.

Estas son las que tengo configuradas:

CPU alta sostenida:

  • Condición: CPU > 90% durante 10 minutos
  • Por qué: picos cortos son normales, pero si dura, algo está mal

Memoria baja:

  • Condición: Memoria disponible < 500MB
  • Por qué: antes de que empiece el swap, prefiero saberlo

Disco casi lleno:

  • Condición: Disco > 85%
  • Por qué: cuando llega al 100%, ya es tarde

Servicio caído:

  • Condición: probe_success == 0 durante 2 minutos
  • Por qué: un fallo puntual puede ser red, pero si dura, hay problema

Temperatura alta:

  • Condición: Temperatura > 75°C
  • Por qué: los discos duros empiezan a sufrir a partir de ahí

Errores que cometí (para que tú no los cometas)
#

Error 1: Scraping cada 5 segundos
#

Al principio pensé “más datos = mejor”. Puse el scrape_interval a 5 segundos. Resultado: Prometheus comía CPU como loco y el almacenamiento crecía a 2GB por semana.

Cambié a 15 segundos y no noté diferencia en la utilidad de las métricas. Para un homelab, 15-30 segundos es más que suficiente.

Error 2: No limitar la retención de datos
#

Prometheus guarda todo por defecto. Mi primera instalación llegó a 300GB de métricas antes de que me diera cuenta. Ahora uso --storage.tsdb.retention.time=90d y estoy en unos 50GB.

Si necesitas históricos más largos, usa Thanos o manda las métricas a Grafana Cloud (tienen tier gratuito).

Error 3: Alertas por todo
#

La primera semana configuré alertas para CPU > 50%, memoria > 60%, disco > 50%. Me llegaban 20 notificaciones al día.

Resultado: dejé de mirarlas.

Ahora solo alerto cuando algo es crítico de verdad. Menos ruido, más señal.

Error 4: No etiquetar los targets
#

Al principio todos mis node-exporters se llamaban igual en Prometheus. Cuando veía una alerta de “CPU alta”, tenía que adivinar qué nodo era.

Ahora uso labels en el prometheus.yml:

1
2
3
4

- targets: ['192.168.1.10:9100']
  labels:
    hostname: 'proxmox-1'
    role: 'compute'

Así las alertas dicen exactamente qué máquina tiene el problema.

PromQL: queries útiles que uso todos los días
#

PromQL es raro al principio. No es SQL. Pero una vez le pillas el truco, es potente.

CPU promedio del cluster:

1

avg(100 - (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100))

Memoria total usada en GB:

1

sum(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / 1024 / 1024 / 1024

Tráfico de red (subida) en Mbps:

1

rate(node_network_transmit_bytes_total{device="eth0"}[5m]) * 8 / 1000 / 1000

Top 5 contenedores por CPU:

1

topk(5, rate(container_cpu_usage_seconds_total[5m]))

Disco que más rápido crece:

1

predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[1h], 7*24*3600)

Esa última es brutal. Te dice cuánto espacio libre tendrás en 7 días basándose en la tendencia de la última hora. Perfecto para detectar logs que crecen sin control.

Integración con Home Assistant
#

Si tienes Home Assistant, puedes mandar métricas desde Prometheus hacia allá y crear automatizaciones basadas en ellas.

Por ejemplo, yo tengo una automatización que enciende un ventilador USB apuntando al rack cuando la temperatura del NAS pasa de 60°C. Funciona sorprendentemente bien.

También mando notificaciones push al móvil cuando algún servicio cae. Útil cuando estás fuera de casa y alguien te dice “oye, el Plex no va”.

Alternativas que consideré y por qué no
#

Netdata: Bonito, rápido, fácil de instalar. Pero orientado a un solo nodo. En cuanto tienes múltiples máquinas, se complica. Además, las alertas son limitadas.

Zabbix: El veterano. Funciona, es potente, tiene todo lo que necesitas. Pero la UI parece de 2005 y configurarlo es un dolor. Si trabajas en una empresa grande, probablemente uses Zabbix. Para homelab, paso.

Checkmk: Similar a Zabbix pero con mejor UX. Consideré seriamente cambiarme, pero la realidad es que Prometheus + Grafana tienen mejor soporte de la comunidad para contenedores.

InfluxDB + Telegraf + Grafana (stack TIG): Muy parecido a Prometheus pero usa InfluxDB como backend. Probé ambos y Prometheus me resultó más fácil de mantener. InfluxDB tiene sus ventajas (mejor compresión, queries SQL-like), pero para homelab, Prometheus es suficiente.

Recursos y consumo
#

Actualmente, todo el stack de monitorización consume:

  • Prometheus: ~300MB RAM, 1-2% CPU
  • Grafana: ~150MB RAM, <1% CPU
  • Node Exporter: ~30MB RAM por instancia
  • cAdvisor: ~100MB RAM por instancia
  • Blackbox Exporter: ~20MB RAM

Total: menos de 1GB de RAM y CPU casi despreciable. En un homelab moderno, es nada.

El almacenamiento depende de cuántas métricas saques y la retención. Con 4 nodos, 30 contenedores, y 90 días de retención, estoy en unos 50GB.

Próximos pasos: federación y Thanos
#

Ahora mismo tengo un solo Prometheus. Funciona bien, pero si algún día el nodo principal cae, pierdo las métricas hasta que lo levante.

La solución “pro” es usar Thanos, que permite:

  • Federación de múltiples Prometheus
  • Almacenamiento de largo plazo en S3/Minio
  • Alta disponibilidad
  • Queries cross-cluster

Lo tengo en la lista de “proyectos para cuando tenga tiempo”. O sea, nunca. Pero si tu homelab es crítico (tipo si alojas servicios para otros), Thanos es el siguiente nivel.

Conclusión: vale la pena el esfuerzo
#

Montar Grafana y Prometheus me llevó un fin de semana. Ajustarlo a mis necesidades, otro par de semanas de ir probando queries y dashboards.

Desde entonces:

  • He detectado 3 discos duros antes de que murieran (temperatura subiendo progresivamente)
  • Identifiqué un contenedor con un memory leak que habría tirado el nodo en unos días
  • Supe exactamente cuándo mi ISP tuvo problemas (gráfica de latencia)
  • Documenté el consumo real de recursos para dimensionar el siguiente nodo

Si tu homelab tiene más de 3 servicios corriendo, necesitas monitorización. No porque sea cool tener dashboards con gráficas, sino porque te ahorra tiempo y disgustos.

Empieza con Docker Compose, importa un dashboard de Node Exporter, configura una alerta básica de disco lleno, y ya tienes el 80% del valor con el 20% del esfuerzo.

El resto lo vas añadiendo conforme lo necesites.