Instalar con Docker

DumbMonit se ejecuta como un único contenedor: el servidor dumbmonit (recolección, API, alertas, interfaz web) arranca su propia VictoriaMetrics para almacenar las series temporales; el binario viene en la imagen. La configuración y el estado viven en una base de datos SQLite integrada. Un volumen, /data, contiene la base de datos, el secreto de la instancia y las series temporales.

Etiquetas de imagen

ghcr.io/laupernoe/dumbmonit:latest es la última versión etiquetada (amd64; las imágenes arm64 están en pausa por ahora); :edge sigue el último commit de dev. Para ejecutar desde el código fuente, docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build compila la misma imagen en local (unos diez minutos la primera vez; solo hace falta Docker).

Requisitos previos

• Docker Engine con el plugin Compose (docker compose version funciona).
• Una máquina que pueda alcanzar los monitores que quieres monitorizar. No necesita ser accesible desde ellos, salvo para los agentes, que envían sus mediciones al servidor por HTTP.
• El puerto 8080 libre en el host, u otro puerto de tu elección (ver más abajo).

El archivo Compose

Este es el docker-compose.yml completo (no hace falta ningún archivo .env); guárdalo en un directorio propio:

services:
  dumbmonit:
    image: ghcr.io/laupernoe/dumbmonit:latest
    ports:
      - "8080:8080"
    volumes:
      - dumbmonit-data:/data
      # Or a host directory; on a SELinux host (Fedora, RHEL) add `:Z`:
      # - ./dumbmonit:/data:Z
    # environment:
    #   PUID: "1000"   # owner of the files in /data (default 65532)
    #   PGID: "1000"
    restart: unless-stopped
    stop_grace_period: 30s
    read_only: true
    tmpfs: [/tmp]
    # Starts as root only to give /data to user 65532 (or PUID/PGID), then
    # drops root for good: a host directory works as it is. Remove `user` and
    # `cap_add` to run as 65532 from the start (the files must belong to it).
    user: "0:0"
    cap_drop: [ALL]
    cap_add: [CHOWN, DAC_READ_SEARCH, SETUID, SETGID]
    security_opt: ["no-new-privileges:true"]
    sysctls:
      net.ipv4.ping_group_range: "0 2147483647"

volumes:
  dumbmonit-data:
    name: dumbmonit-data

Después, arráncalo:

docker compose up -d

Se descarga la imagen publicada; el sistema de archivos de solo lectura, las capabilities, PUID/PGID y el sysctl ping_group_range se explican en Permisos y directorio de datos y Ping ICMP sin capability. Las opciones (puerto, secreto, retención, VictoriaMetrics externa, capturas) son variables de entorno que añades tú mismo.

Compilar la imagen tú mismo

Desde un clon del repositorio, docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build compila la misma imagen en local (unos diez minutos en frío; no hace falta ninguna toolchain de Rust ni de Node en el host). Úsalo para ejecutar desde el código fuente o desde una rama.

VictoriaMetrics integrada

La imagen contiene el binario de VictoriaMetrics (/victoria-metrics-prod, de victoriametrics/victoria-metrics:v1.152.0). Cuando DUMBMONIT_VM_URL no está definida, el servidor lo inicia como proceso hijo escuchando en 127.0.0.1:8428, guarda sus series en /data/vm, redirige sus líneas de log al log propio, lo reinicia con espera progresiva si se cae y lo detiene al apagarse. No se publica nada: el puerto se queda dentro del contenedor.

Conviene conocer dos variables: DUMBMONIT_VM_RETENTION (12 meses por defecto; 30d o 2y también valen) y DUMBMONIT_VM_MEMORY (256MB, el presupuesto de sus cachés; auméntalo para cientos de hosts). El resto está en la referencia de configuración.

Para usar una VictoriaMetrics que ya tengas en marcha, define DUMBMONIT_VM_URL con su dirección (http://host:8428): la integrada entonces no se inicia y /data/vm queda vacío.

Primer inicio

Abre https://<tu-host>:8080. El navegador muestra un aviso una sola vez por el certificado autofirmado (consulta HTTPS and encryption). Una instancia nueva muestra la pantalla /setup, donde creas la primera cuenta de administrador (contraseña de al menos 12 caracteres).

La pantalla pide primero el código de configuración. Mientras no exista ningún administrador, el servidor imprime un código de un solo uso en sus logs al arrancar:

docker compose logs dumbmonit | grep -A1 "setup code"

  First-run setup code: K7XQ4-M9PRT

Demuestra que quien crea la cuenta de administrador controla el servidor, de modo que nadie más en la red pueda reclamar antes una instancia nueva. El código vive solo en memoria, cambia en cada reinicio hasta que exista un administrador, y los intentos fallidos tienen límite de tasa. Para un despliegue automatizado, define DUMBMONIT_SETUP_CODE y elígelo tú mismo.

Después añade tu primer monitor: consulta Añade tu primer monitor.

Variables de entorno

Todo se configura mediante variables de entorno; ninguna es obligatoria. Añade las que necesites bajo environment: del servicio, como se muestra en Opciones avanzadas.

Variable	Valor por defecto	Función
DUMBMONIT_BIND	0.0.0.0:8080	Dirección de escucha dentro del contenedor.
PUID / PGID	65532	Con user: "0:0": usuario y grupo con los que se ejecuta el servidor, y propietario de los archivos de /data (detalles). DUMBMONIT_PUID / DUMBMONIT_PGID también funcionan.
DUMBMONIT_DATA_DIR	/data	Base de datos SQLite (dumbmonit.db), secreto de la instancia (secret.key) y los datos de la VictoriaMetrics integrada (vm/).
DUMBMONIT_VM_URL	(sin definir)	URL de una VictoriaMetrics externa. Si se define, la integrada no se inicia.
DUMBMONIT_VM_RETENTION	12	Retención de la VictoriaMetrics integrada: meses, o 30d, 2y.
DUMBMONIT_VM_MEMORY	256MB	Presupuesto de memoria de las cachés de la VictoriaMetrics integrada.
DUMBMONIT_VM_LISTEN	127.0.0.1:8428	Dirección de escucha de la VictoriaMetrics integrada, dentro del contenedor.
DUMBMONIT_SECRET	(generado)	Secreto de la instancia que cifra las credenciales de los monitores y los tokens.
DUMBMONIT_MAX_CONCURRENT_PROBES	64	Sondeos simultáneos, todos los colectores combinados.
DUMBMONIT_PROBE_TIMEOUT_SECS	10	Duración máxima de un sondeo.
DUMBMONIT_FLUSH_INTERVAL_SECS	5	Periodo de escritura hacia VictoriaMetrics.
DUMBMONIT_LOG	info	Filtro de logs (sintaxis de tracing, p. ej. debug, dumbmonit=trace).
DUMBMONIT_AGENT_DIR	/agents	Binarios de los agentes servidos bajo /download/….
DUMBMONIT_RESET_PASSWORD	(vacío)	Defínela como 1 para borrar la contraseña y todas las sesiones al arrancar.
DUMBMONIT_SETUP_CODE	(generado)	Código de configuración que pide /setup mientras no exista un administrador. Sin definir, se imprime uno aleatorio en los logs en cada arranque.
DUMBMONIT_COOKIE_SECURE	(desactivado)	Defínela como 1 tras un proxy inverso TLS para marcar la cookie de sesión como Secure.
DUMBMONIT_ALERT_INTERVAL_SECS	30	Periodo de evaluación de alertas (nunca por debajo de 10).
DUMBMONIT_ALERT_HISTORY_DAYS	90 días	Retención del historial de alertas. Consulta la referencia de configuración para una salvedad sobre su unidad.
DUMBMONIT_BACKUP_ENABLED	activado	Copias de seguridad locales programadas de la base de datos en /data/backups/. DUMBMONIT_BACKUP_DIR, _INTERVAL_HOURS (24) y _KEEP (7) las ajustan; consulta Copia de seguridad y restauración.

La lista completa, con detalles, está en la referencia de configuración. Los nombres EZYMONIT_* anteriores al cambio de nombre se siguen leyendo como alternativa; consulta Actualización.

Copia de seguridad de la clave secreta

Las comunidades SNMP, las contraseñas y los tokens de API se cifran con AES-256-GCM usando una clave derivada del secreto de la instancia. En el primer inicio, DumbMonit genera este secreto en /data/secret.key (dentro del volumen dumbmonit-data).

Respalda secret.key junto con la base de datos

Sin ella, las credenciales de los monitores son irrecuperables: una base de datos restaurada sola da una instancia incapaz de comunicarse con nada. El servidor detecta al arrancar una clave ausente o modificada y se niega a continuar con un mensaje explícito, en lugar de fallar en silencio en cada sondeo. Las copias programadas la incluyen por ti — consulta Copia de seguridad y restauración.

Si prefieres controlar el secreto, define DUMBMONIT_SECRET en el archivo Compose (ejemplo) (32 caracteres aleatorios o más). Guárdalo en tu gestor de contraseñas.

Actualización

docker compose pull
docker compose up -d

Las migraciones de la base de datos se ejecutan al arrancar. Los datos de VictoriaMetrics no se tocan.

Haz antes una copia de seguridad

Settings → Backup → Back up now escribe en unos segundos una copia consistente de la base de datos y de secret.key en /data/backups/, y es desde donde restauras si la actualización sale mal. Consulta Copia de seguridad y restauración.

Bind mounts

Un docker-compose.yml existente sigue funcionando tal cual: la imagen sigue ejecutándose como usuario 65532. El archivo nuevo añade user: "0:0" y una línea cap_add para que un directorio del host funcione sin preparación (Permisos); copia esas dos líneas si quieres pasar a un bind mount.

Desde EzyMonit y desde la configuración de dos contenedores

DumbMonit se llamó EzyMonit hasta septiembre de 2026, y se ejecutaba como dos contenedores, el servidor y un servicio victoriametrics aparte. Actualizar exige mover una vez los datos del proyecto antiguo al nuevo volumen. El proyecto antiguo se llamaba ezymonit (sus volúmenes, ezymonit_ezymonit-data y ezymonit_vm-data; docker volume ls lo confirma). Desde el directorio antiguo:

docker compose down

Después, con el nuevo docker-compose.yml:

docker volume create dumbmonit-data
docker run --rm -v ezymonit_ezymonit-data:/from -v dumbmonit-data:/to alpine cp -a /from/. /to/
docker run --rm -v ezymonit_vm-data:/from -v dumbmonit-data:/to alpine sh -c 'mkdir -p /to/vm && cp -a /from/. /to/vm/'
docker compose up -d

El antiguo directorio de datos de VictoriaMetrics tiene la estructura que usa la integrada: nada que convertir. La alternativa es conservar la VictoriaMetrics externa y apuntar DUMBMONIT_VM_URL hacia ella.

Lo que el servidor gestiona por sí solo en el primer inicio:

• Las variables EZYMONIT_* se siguen leyendo como alternativa, con un aviso al arrancar por variable (EZYMONIT_X is deprecated, use DUMBMONIT_X).
• /data/ezymonit.db se renombra a dumbmonit.db.
• Los tokens de agente ezym_… siguen funcionando; los nuevos son dmon_…. Los agentes siguen enviando datos; vuelve a ejecutar el comando de instalación en cada máquina cuando te venga bien, así migra el servicio antiguo en el sitio.
• La cookie de sesión cambió de nombre: todo el mundo vuelve a iniciar sesión una vez. Se conserva la preferencia de tema del navegador.

Lo que no gestiona: el prefijo de las métricas cambió de ezymonit_ a dumbmonit_ sin compatibilidad. Las series antiguas permanecen en VictoriaMetrics con el nombre antiguo y caducan según la retención; las gráficas y las reglas integradas reinician desde la actualización. Las reglas de alerta personalizadas que nombren métricas ezymonit_… deben editarse.

Copia de seguridad y restauración

Un único volumen con nombre, dumbmonit-data, lo contiene todo:

Ruta	Contenido
dumbmonit.db	Monitores, reglas, canales, estado de las alertas, sesiones.
secret.key	El secreto de la instancia.
backups/	Las copias locales programadas: una copia de la base de datos y del secreto, diaria por defecto, siete conservadas.
vm/	Series temporales de VictoriaMetrics (12 meses de retención por defecto).

DumbMonit respalda su propia base de datos de forma programada, y exporta toda la configuración — monitores, credenciales, reglas, canales — como un único archivo cifrado con una frase de contraseña que tú eliges, que se restaura en una instancia nueva. Ambas opciones están en Copia de seguridad y restauración, junto con lo que hay que hacer antes de una actualización y la única regla sobre secret.key que conviene leer dos veces.

Para archivar el propio volumen, gráficas incluidas, detén la pila y comprímelo con tar:

docker compose stop
docker run --rm -v dumbmonit-data:/data -v "$PWD:/backup" alpine \
  tar czf /backup/dumbmonit-data.tgz -C /data .
docker compose start

Para restaurar, crea el volumen, extrae el archivo en él del mismo modo y después docker compose up -d.

Si el espacio importa, --exclude=./vm mantiene el archivo pequeño: la base de datos y el secreto son la configuración, vm/ son solo las gráficas.

Opciones avanzadas

El archivo Compose de arriba no lleva variables a propósito. Para cambiar un ajuste, añade un bloque environment: (o una línea en él) bajo dumbmonit: en tu docker-compose.yml y ejecuta de nuevo docker compose up -d. El contenedor se recrea; el volumen de datos se conserva.

Otro puerto. Cambia el lado izquierdo del mapeo; el contenedor sigue escuchando en el 8080:

    ports:
      - "8099:8080"

Tu propio secreto, en lugar del generado en /data/secret.key. Cifra las credenciales de los monitores: perderlo significa volver a introducirlas todas.

    environment:
      DUMBMONIT_SECRET: replace-me-with-32-random-characters

Retención y memoria de la VictoriaMetrics integrada (meses, o 30d / 2y; un homelab de unas pocas docenas de monitores cabe en 256 MB):

    environment:
      DUMBMONIT_VM_RETENTION: "24"
      DUMBMONIT_VM_MEMORY: 512MB

VictoriaMetrics externa; la integrada entonces no se inicia:

    environment:
      DUMBMONIT_VM_URL: http://victoriametrics:8428

Contraseña perdida. Añade la línea de abajo, ejecuta docker compose up -d, vuelve a crear el primer administrador en la interfaz (los monitores, reglas y canales se conservan), quita después la línea y ejecuta docker compose up -d una vez más:

    environment:
      DUMBMONIT_RESET_PASSWORD: "1"

Capturas de pantalla de los cambios de sitios web: un Chromium sin interfaz junto al servidor; véase más abajo Capturas de pantalla de los cambios de sitios web.

Más variables: referencia de configuración.

Capturas de pantalla de los cambios de sitios web

El monitor de cambios de sitios web siempre compara el texto visible de las páginas. Guardar una captura de pantalla de cada versión nueva requiere un navegador, y la imagen de DumbMonit no incluye ninguno: un Chromium sin interfaz se ejecuta como segundo servicio, y DUMBMONIT_BROWSER_URL indica al servidor dónde encontrarlo.

Añada estas líneas a su docker-compose.yml y ejecute después docker compose up -d:

services:
  dumbmonit:
    environment:
      DUMBMONIT_BROWSER_URL: http://browser:9222
  browser:
    image: chromedp/headless-shell:stable
    shm_size: 256m
    restart: unless-stopped

• browser es el nombre del servicio; en la red de Compose, http://browser:9222 lleva hasta él. Nada publica su puerto: solo DumbMonit habla con él.
• shm_size: 256m: Chromium renderiza en /dev/shm, y los 64 MB por defecto de Docker son demasiado pocos para una página larga.
• Sirve cualquier Chromium iniciado con --remote-debugging-port; aquí se usa la imagen chromedp/headless-shell.

Sin navegador, todo lo demás funciona como siempre (comparación de texto, alertas, copias antes/después); las instantáneas simplemente no tienen imagen. Mientras el servidor no alcance ningún navegador, el formulario de un monitor de cambios de sitio web muestra un aviso con estas líneas. Si el aviso sigue tras el reinicio, revise docker compose logs browser, que el nombre de host de DUMBMONIT_BROWSER_URL sea el nombre del servicio y que ambos servicios estén en el mismo proyecto de Compose.

Proxy inverso

La interfaz y la API se sirven en un solo puerto, que solo habla HTTPS (una petición HTTP simple recibe una redirección, consulta HTTPS and encryption). Un proxy inverso debe conectarse al contenedor por HTTPS (https://dumbmonit:8080), con la verificación del certificado desactivada para ese tramo o con el certificado de DumbMonit como confiable. No se usa WebSocket: la interfaz consulta la API periódicamente, así que cualquier proxy inverso funciona sin configuración especial.

monit.example.com {
    reverse_proxy https://127.0.0.1:8080 {
        transport http {
            tls_insecure_skip_verify
        }
    }
}

server {
    listen 443 ssl;
    server_name monit.example.com;
    # ssl_certificate / ssl_certificate_key …

    location / {
        proxy_pass https://127.0.0.1:8080;
        proxy_ssl_verify off;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        # Los agentes envían lotes de recuperación tras una interrupción:
        client_max_body_size 16m;
    }
}

Cuando el proxy termina TLS, define DUMBMONIT_COOKIE_SECURE: "1" para que la cookie de sesión solo se envíe por HTTPS. Defínela solo si todos los navegadores llegan a DumbMonit por HTTPS: el navegador nunca devolvería la cookie y sería imposible iniciar sesión.

Agentes detrás de un proxy

El comando de instalación que se muestra al crear un token de agente usa la URL con la que tu navegador accedió a la interfaz. Si es la URL del proxy, los agentes también la usarán: asegúrate de que /install.sh, /install.ps1, /download/… y /api/ingest pasan por el proxy.

Permisos y directorio de datos

El servidor nunca se ejecuta como root. Por defecto, la imagen se ejecuta como usuario 65532:65532, al que ya pertenece un volumen con nombre creado por Docker.

Un bind mount (./dumbmonit:/data), en cambio, conserva el propietario del directorio del host, a menudo root cuando lo creó Docker. Por eso el archivo Compose de arriba inicia el contenedor como root (user: "0:0"). El servidor solo sigue siendo root un instante: antes de abrir la base de datos, iniciar VictoriaMetrics o escuchar en la red, entrega /data a 65532:65532 (solo las entradas que pertenecen a otro, sin seguir enlaces simbólicos), abandona root de forma definitiva y comprueba que no puede recuperarlo. Las cuatro capabilities de cap_add son solo para este paso; ninguna queda después. no-new-privileges y el sistema de archivos raíz de solo lectura siguen activos: /data y /tmp son las únicas rutas escribibles.

Elegir el propietario: PUID y PGID. Con user: "0:0", indica el uid y el gid con los que se ejecuta el servidor; los archivos se les entregan al arrancar:

    environment:
      PUID: "1000"
      PGID: "1000"

DUMBMONIT_PUID / DUMBMONIT_PGID también funcionan y tienen prioridad. Se rechaza 0. En Unraid, PUID=99 y PGID=100 coinciden con el propietario habitual de appdata. Sin user: "0:0", PUID/PGID se ignoran.

Sin user: "0:0" (un simple docker run -v ./data:/data, o --user 1000:1000), no cambia ningún propietario y /data ya debe ser escribible. Si no lo es, el servidor se detiene y sugiere primero --user 0:0, y después sudo chown -R 65532:65532 ./data en el host para un bind mount o, para un volumen con nombre:

docker run --rm -v dumbmonit-data:/data alpine chown -R 65532:65532 /data

SELinux y Podman

En un host donde SELinux está en modo enforcing (Fedora, RHEL, CentOS Stream, AlmaLinux…), se deniega al contenedor un bind mount, incluso siendo root, mientras no lleve una etiqueta de contenedor. Añade :Z al volumen, o :z si otros contenedores comparten el directorio:

    volumes:
      - ./dumbmonit:/data:Z

Sin ella, el servidor se detiene con the host enforces SELinux and the volume has no container label. Docker etiqueta los volúmenes con nombre, así que no necesitan nada.

Podman sin root funciona igual, con --user 0:0. Root en el contenedor es tu propio usuario en el host, y los archivos de un bind mount pasan al uid 65532 del contenedor, que el host muestra como uno de tus sub-uids (165531 con el /etc/subuid habitual). Léelos con podman unshare ls -l ./dumbmonit. Para conservarlos con tu propio uid, ejecuta el contenedor como tú mismo; entonces no cambia ningún propietario:

podman run --userns keep-id --user "$(id -u):$(id -g)" -v ./dumbmonit:/data:Z …

Ping ICMP sin capability

El monitor de ping envía ecos ICMP. En lugar de un socket raw — que necesita NET_RAW, y una capability concedida a un usuario no root del contenedor no es utilizable de todos modos —, usa un socket ICMP echo, que Linux permite a los grupos listados en net.ipv4.ping_group_range. El archivo Compose define ese sysctl dentro del espacio de nombres de red del propio contenedor:

services:
  dumbmonit:
    sysctls:
      net.ipv4.ping_group_range: "0 2147483647"

Nada cambia en el host. Docker 20.10 y posteriores definen este rango por sí mismos en cada contenedor; las líneas explícitas hacen que se cumpla en motores más antiguos y en Podman. Sin él, la comprobación informa de un error de configuración (se muestra en el monitor, no se notifica), nunca de un falso «host caído». Con docker run, pasa --sysctl net.ipv4.ping_group_range="0 2147483647". Mientras el servidor no pueda abrir un socket ICMP, el formulario de un monitor ping muestra un aviso con estas líneas.

Probar sin hardware

Añade un monitor de demostración: produce mediciones falsas sin nada que preparar, así que se pueden probar las gráficas, las reglas y las notificaciones enseguida. Para datos SNMP reales, la máquina que ejecuta Docker suele bastar — instala snmpd en ella (apt install snmpd, permite la comunidad public en el bridge de Docker en /etc/snmp/snmpd.conf) y añade un dispositivo SNMP con la dirección del host en ese bridge (172.17.0.1 por defecto): el perfil se detecta automáticamente y aparecen interfaces, memoria y procesos.

Los desarrolladores pueden añadir el overlay docker-compose.dev.yml para publicar la VictoriaMetrics integrada en el :8428 del host y hacer consultas MetricsQL directas:

docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d