Problema

En muchos homelabs se adopta la estrategia “un servicio, una VM o LXC”. La separación facilita la gestión de permisos y la actualización individual, pero introduce un nuevo punto crítico: la falta de visibilidad centralizada. Cuando un contenedor o máquina virtual se cae, el único aviso suele ser la ausencia de respuesta del servicio, detectada horas después. Además, la proliferación de redes aisladas (subnet routers, Tailscale, IP estáticas) complica la identificación del origen del fallo. El resultado es tiempo de inactividad no planificado y una carga operativa innecesaria para el administrador.

Causa

  1. Ausencia de health‑checks automáticos – La mayoría de los LXC y VM se inician sin scripts que verifiquen que la aplicación dentro está respondiendo. Un proceso que se reinicia o que entra en estado “crash‑loop” pasa desapercibido hasta que el usuario lo invoca.
  2. Monitoreo local limitado a la capa de hardware – Proxmox muestra el estado de la VM (running, stopped) pero no la salud de la aplicación. Un contenedor puede estar “up” mientras su proceso interno está colgado.
  3. Redes superpuestas sin métricas – Cuando se usan túneles como Tailscale o routers LXC, la IP que se debe pinguear varía según la ubicación del cliente. Sin un mapa de rutas dinámico, los checks de conectividad fallan o se hacen manualmente.
  4. Logs dispersos – Cada contenedor escribe en su propio archivo dentro del filesystem de la VM. Sin un colector central, buscar la causa de un reinicio implica acceder a múltiples shells.
  5. Escalabilidad de la solución de gestión – Herramientas como Portainer simplifican la orquestación de Docker, pero no sustituyen a un sistema de alertas que cubra tanto Docker como LXC y VM.

Solución

Implementar una capa ligera de monitoring que cubra:

  • Health‑checks a nivel de aplicación mediante systemd o scripts cron dentro de cada LXC/VM.
  • Exportador de métricas (por ejemplo, Prometheus Node Exporter o cAdvisor para Docker) desplegado en cada host Proxmox.
  • Agente de recolección de logs como Filebeat o Fluent Bit que envíe logs a un único servidor Elasticsearch o a Grafana Loki.
  • Alertmanager configurado para enviar notificaciones por correo, Telegram o Discord cuando una métrica cruce umbrales predefinidos.
  • Dashboard unificado en Grafana que muestre:
    • Estado de cada VM/LXC (up/down).
    • Latencia de ping a IP estáticas y a la IP del túnel Tailscale.
    • Uso de CPU/RAM de cada contenedor.
    • Últimos eventos de logs críticos.

Paso a paso resumido

  1. Instalar Node Exporter en cada nodo Proxmox

    wget https://github.com/prometheus/node_exporter/releases/download/v1.8.1/node_exporter-1.8.1.linux-amd64.tar.gz
tar xzf node_exporter-1.8.1.linux-amd64.tar.gz
sudo cp node_exporter-1.8.1.linux-amd64/node_exporter /usr/local/bin/
sudo useradd -rs /bin/false node_exporter
sudo tee /etc/systemd/system/node_exporter.service > /dev/null <<EOF
[Unit]
Description=Prometheus Node Exporter
After=network.target

[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=default.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

  2. Desplegar cAdvisor en un contenedor Docker (monitoriza contenedores Docker dentro de LXC o VM).

    docker run -d \
  --name=cadvisor \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --publish=8080:8080 \
  gcr.io/cadvisor/cadvisor:latest

  3. Configurar Filebeat en cada host para enviar logs a Loki.

    filebeat.inputs:
- type: log
  paths:
    - /var/log/**/*.log
output.logstash:
  hosts: ["loki.example.com:5044"]

  4. Crear reglas de alertas en Alertmanager

    route:
  receiver: telegram
receivers:
- name: telegram
  telegram_configs:
  - bot_token: "123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
    chat_id: "-1001234567890"
inhibit_rules:
- source_match:
    severity: "critical"
  target_match:
    severity: "warning"

  5. Diseñar paneles en Grafana que consulten Prometheus y Loki. Incluir gráficos de “up{job=‘node’}” y “container_cpu_usage_seconds_total”.

Con esta arquitectura, cualquier caída – ya sea del proceso interno, del contenedor Docker o de la VM – genera una métrica “down” que dispara una alerta inmediata, sin necesidad de inspeccionar manualmente cada IP.

Cuándo aplicar esta solución

  • Entornos con >5 servicios críticos distribuidos en varios contenedores/VM.
  • Redes mixtas (NFS, Tailscale, VLAN) donde la conectividad varía según la ubicación del cliente.
  • Necesidad de detección proactiva: si actualmente descubres fallos sólo al intentar usar el servicio.
  • No aplicable cuando el homelab es un único servidor con un par de servicios que pueden ser revisados manualmente; la sobrecarga de Prometheus + Grafana sería innecesaria.

Código

# Script de health‑check simple para una aplicación web dentro de un LXC
#!/usr/bin/env bash
URL="http://127.0.0.1:8080/healthz"
if curl -fs "$URL" > /dev/null; then
  exit 0
else
  systemctl restart myapp.service
  exit 1
fi

Guárdalo como /usr/local/bin/app-healthcheck.sh, hazlo ejecutable y añádelo a crontab:

*/5 * * * * /usr/local/bin/app-healthcheck.sh

Verificación

  1. Node Exporter: curl http://<host_ip>:9100/metrics | grep node_cpu_seconds_total.
  2. cAdvisor: abre http://<host_ip>:8080/containers/ y verifica que tus contenedores aparecen.
  3. Alertmanager: fuerza una caída (por ejemplo, mata el proceso de la app) y comprueba que recibes el mensaje en Telegram.
  4. Grafana: revisa que el panel “Service uptime” muestra una línea roja en el momento del fallo.
  5. Filebeat: busca en Loki una entrada reciente del contenedor que falló para confirmar que los logs se están enviando.

Notas adicionales

  • IP estáticas vs DHCP – Mantener direcciones fijas simplifica los checks de ping, pero si usas Tailscale, consulta la variable tailscale ip -4 dentro del contenedor para obtener la IP correcta en tiempo real.
  • Recursos de Prometheus – En un homelab con pocos nodos, limitar la retención a 7‑15 días evita que la base de datos crezca demasiado.
  • Backup de configuración – Exporta los dashboards de Grafana y la configuración de Alertmanager a un repositorio Git; así puedes restaurarlos rápidamente tras una reinstalación de Proxmox.
  • Portainer – Sigue siendo útil para gestionar Docker dentro de un LXC, pero no sustituye al monitoreo de nivel host. Usa Portainer para despliegues y Grafana/Prometheus para observabilidad.
  • Seguridad – Asegúrate de que los puertos de Prometheus (9090) y Alertmanager (9093) estén accesibles solo desde la red interna o a través de VPN/Tailscale; exponerlos a internet es un riesgo innecesario.