Installation avec Docker

DumbMonit tourne dans un seul conteneur : le serveur dumbmonit (collecte, API, alertes, interface web) démarre son propre VictoriaMetrics pour le stockage des séries temporelles ; le binaire est fourni dans l’image. La configuration et l’état vivent dans une base SQLite embarquée. Un seul volume, /data, contient la base, le secret de l’instance et les séries temporelles.

Tags d’image

ghcr.io/laupernoe/dumbmonit:latest est la dernière version étiquetée (amd64 ; les images arm64 sont suspendues pour l’instant) ; :edge suit le dernier commit de dev. Pour exécuter depuis les sources, docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build construit la même image en local (environ dix minutes la première fois ; seul Docker est nécessaire).

Prérequis

• Docker Engine avec le plugin Compose (docker compose version fonctionne).
• Une machine qui peut joindre les surveillances à surveiller. Elle n’a pas besoin d’être joignable depuis eux, sauf pour les agents, qui poussent leurs mesures vers le serveur par son port agents chiffré (TCP 8443, voir Sécurité du canal des agents).
• Le port 8080 libre sur l’hôte, ou un autre port de votre choix (voir plus bas).

Le fichier Compose

Voici le docker-compose.yml complet (aucun fichier .env nécessaire) ; enregistrez-le dans un répertoire dédié :

services:
  dumbmonit:
    image: ghcr.io/laupernoe/dumbmonit:latest
    ports:
      - "8080:8080"
      # Encrypted agent channel: see Agent channel security.
      - "8443:8443"
    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

Puis démarrez-le :

docker compose up -d

L’image publiée est récupérée ; le système de fichiers en lecture seule, les capabilities, PUID/PGID et le sysctl ping_group_range sont expliqués dans Permissions et répertoire de données et Ping ICMP sans capability. Les options (port, secret, rétention, VictoriaMetrics externe, captures d’écran) sont des variables d’environnement que vous ajoutez vous-même.

Construire l’image vous-même

Depuis un clone du dépôt, docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build construit la même image en local à la place (environ dix minutes à froid ; aucune chaîne d’outils Rust ou Node n’est nécessaire sur l’hôte). Utilisez-le pour exécuter depuis les sources ou depuis une branche.

VictoriaMetrics embarqué

L’image contient le binaire VictoriaMetrics (/victoria-metrics-prod, issu de victoriametrics/victoria-metrics:v1.154.0). Lorsque DUMBMONIT_VM_URL n’est pas défini, le serveur le démarre comme processus enfant à l’écoute sur 127.0.0.1:8428, stocke ses séries sous /data/vm, redirige ses lignes de journal vers le sien, le redémarre avec un délai croissant s’il meurt et l’arrête à l’extinction. Rien n’est publié : le port reste à l’intérieur du conteneur.

Deux variables sont à connaître : DUMBMONIT_VM_RETENTION (12 mois par défaut ; 30d ou 2y fonctionnent aussi) et DUMBMONIT_VM_MEMORY (256MB, le budget de ses caches ; augmentez-le pour des centaines d’hôtes). Le reste se trouve dans la référence de configuration.

Pour utiliser un VictoriaMetrics que vous exploitez déjà, définissez DUMBMONIT_VM_URL à son adresse (http://host:8428) : l’embarqué n’est alors pas démarré et /data/vm reste vide.

Historique long et journaux

Les données brutes sont gardées pendant la rétention ci-dessus, modifiable aussi dans Réglages → Système → Données et rétention. À côté, le serveur écrit des agrégats de 5 minutes dans un second VictoriaMetrics embarqué (/data/vm-long, 730 jours, 64 Mo de cache), et les graphiques, pages de statut et rapports qui remontent plus loin que la rétention brute sont servis depuis lui. VictoriaLogs (/victoria-logs-prod, /data/vlogs) est aussi dans l’image mais reste éteint tant que vous ne l’activez pas au même endroit ; la page Logs cherche alors dans les journaux du serveur. Toutes les variables sont dans la référence de configuration ; les chiffres de disque et de mémoire sont dans Dimensionnement.

Premier démarrage

Ouvrez https://<votre-hôte>:8080. Le navigateur affiche une alerte une seule fois à cause du certificat autosigné (voir HTTPS and encryption). Une instance vierge affiche l’écran /setup, où vous créez le premier compte administrateur (mot de passe d’au moins 12 caractères).

L’écran demande d’abord le code d’installation. Tant qu’aucun administrateur n’existe, le serveur affiche un code à usage unique dans ses journaux au démarrage :

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

  First-run setup code: K7XQ4-M9PRT

Il prouve que la personne qui crée le compte admin exploite le serveur, de sorte que quelqu’un d’autre sur le réseau ne puisse pas s’emparer d’abord d’une instance vierge. Le code ne vit qu’en mémoire, change à chaque redémarrage tant qu’un admin n’existe pas, et les tentatives erronées sont limitées en débit. Pour un déploiement automatisé, définissez DUMBMONIT_SETUP_CODE pour le choisir vous-même.

Ajoutez ensuite votre première surveillance : voir Ajouter votre première surveillance.

Santé du conteneur

L’image définit son propre HEALTHCHECK Docker : Docker, Portainer et Unraid affichent donc le conteneur comme healthy sans réglage supplémentaire. Il exécute dumbmonit healthcheck, qui appelle /api/health depuis l’intérieur du conteneur, sur le port de DUMBMONIT_BIND (8080 par défaut). L’image n’a ni shell ni curl : ne la remplacez pas par un test à base de curl dans votre fichier Compose.

Variables d’environnement

Tout passe par des variables d’environnement ; aucune n’est obligatoire.

Variable	Défaut	Rôle
DUMBMONIT_BIND	0.0.0.0:8080	Adresse d’écoute à l’intérieur du conteneur.
PUID / PGID	65532	Avec user: "0:0" : utilisateur et groupe sous lesquels le serveur s’exécute, et propriétaire des fichiers de /data (détails). DUMBMONIT_PUID / DUMBMONIT_PGID fonctionnent aussi.
DUMBMONIT_DATA_DIR	/data	Base SQLite (dumbmonit.db), secret de l’instance (secret.key) et données du VictoriaMetrics embarqué (vm/).
DUMBMONIT_VM_URL	(non défini)	URL d’un VictoriaMetrics externe. Lorsqu’elle est définie, l’embarqué n’est pas démarré.
DUMBMONIT_VM_RETENTION	12	Rétention du VictoriaMetrics embarqué : mois, ou 30d, 2y.
DUMBMONIT_VM_MEMORY	256MB	Budget mémoire des caches du VictoriaMetrics embarqué.
DUMBMONIT_VM_LISTEN	127.0.0.1:8428	Adresse d’écoute du VictoriaMetrics embarqué, à l’intérieur du conteneur.
DUMBMONIT_SECRET	(généré)	Secret de l’instance qui chiffre les identifiants des surveillances et les jetons.
DUMBMONIT_MAX_CONCURRENT_PROBES	64	Sondes simultanées, tous collecteurs confondus.
DUMBMONIT_PROBE_TIMEOUT_SECS	10	Durée maximale d’une sonde.
DUMBMONIT_FLUSH_INTERVAL_SECS	5	Période d’écriture vers VictoriaMetrics.
DUMBMONIT_LOG	info	Filtre de journalisation (syntaxe tracing, p. ex. debug, dumbmonit=trace).
DUMBMONIT_AGENT_DIR	/agents	Binaires d’agent servis sous /download/….
DUMBMONIT_RESET_PASSWORD	(vide)	Définir à 1 pour effacer le mot de passe et toutes les sessions au démarrage.
DUMBMONIT_SETUP_CODE	(généré)	Code d’installation demandé par /setup tant qu’aucun admin n’existe. Non défini, un code aléatoire est affiché dans les journaux à chaque démarrage.
DUMBMONIT_COOKIE_SECURE	(désactivé)	Définir à 1 derrière un reverse proxy TLS pour marquer le cookie de session Secure.
DUMBMONIT_TLS_CERT / DUMBMONIT_TLS_KEY	(autosigné)	Chaîne de certificats et clé PEM à servir ; relues quand elles changent. Voir HTTPS and encryption.
DUMBMONIT_ALERT_INTERVAL_SECS	30	Période d’évaluation des alertes (jamais en dessous de 10).
DUMBMONIT_ALERT_HISTORY_DAYS	90 jours	Rétention de l’historique des alertes. Voir la référence de configuration pour une réserve sur son unité.
DUMBMONIT_BACKUP_ENABLED	activé	Sauvegardes locales planifiées de la base dans /data/backups/. DUMBMONIT_BACKUP_DIR, _INTERVAL_HOURS (24) et _KEEP (7) les ajustent ; voir Sauvegarde et restauration.

La liste complète, avec les détails, se trouve dans la référence de configuration. Les noms EZYMONIT_* d’avant le renommage sont toujours lus en repli ; voir Mise à jour.

Sauvegarder la clé secrète

Les communautés SNMP, mots de passe et jetons d’API sont chiffrés en AES-256-GCM avec une clé dérivée du secret de l’instance. Au premier démarrage, DumbMonit génère ce secret dans /data/secret.key (dans le volume dumbmonit-data).

Sauvegardez secret.key avec la base de données

Sans elle, les identifiants des surveillances sont irrécupérables : une base restaurée seule donne une instance incapable de parler à quoi que ce soit. Le serveur détecte une clé manquante ou modifiée au démarrage et refuse de continuer avec un message explicite, plutôt que d’échouer silencieusement à chaque sonde. Les sauvegardes planifiées la copient pour vous — voir Sauvegarde et restauration.

Si vous préférez posséder le secret, définissez DUMBMONIT_SECRET dans le fichier Compose (exemple) à la place (32 caractères aléatoires ou plus). Gardez-le dans votre gestionnaire de mots de passe.

Mise à jour

docker compose pull
docker compose up -d

Les migrations de base de données s’exécutent au démarrage. Les données de VictoriaMetrics restent intactes.

Faites d’abord une sauvegarde

Settings → Backup → Back up now écrit en quelques secondes une copie cohérente de la base et de secret.key dans /data/backups/, et c’est de là que vous restaurez si la mise à jour tourne mal. Voir Sauvegarde et restauration.

Bind mounts

Un docker-compose.yml existant continue de fonctionner tel quel : l’image s’exécute toujours sous l’utilisateur 65532. Le nouveau fichier ajoute user: "0:0" et une ligne cap_add pour qu’un répertoire de l’hôte fonctionne sans préparation (Permissions) ; copiez ces deux lignes si vous voulez passer à un bind mount.

Depuis EzyMonit, et depuis l’installation à deux conteneurs

DumbMonit s’appelait EzyMonit jusqu’en septembre 2026, et tournait dans deux conteneurs, le serveur et un service victoriametrics séparé. La mise à jour demande de déplacer une fois les données de l’ancien projet dans le nouveau volume. L’ancien projet s’appelait ezymonit (ses volumes ezymonit_ezymonit-data et ezymonit_vm-data ; docker volume ls le confirme). Depuis l’ancien répertoire :

docker compose down

Puis, avec le nouveau 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

L’ancien répertoire de données de VictoriaMetrics a la structure qu’utilise l’embarqué : rien à convertir. L’alternative est de garder le VictoriaMetrics externe et de pointer DUMBMONIT_VM_URL vers lui.

Ce que le serveur gère seul au premier démarrage :

• Les variables EZYMONIT_* sont toujours lues en repli, avec un avertissement au démarrage par variable (EZYMONIT_X is deprecated, use DUMBMONIT_X).
• /data/ezymonit.db est renommé en dumbmonit.db.
• Les jetons d’agent ezym_… continuent de fonctionner ; les nouveaux sont dmon_…. Les agents continuent de pousser ; relancez la commande d’installation sur chaque machine quand cela vous arrange, elle migre l’ancien service sur place.
• Le cookie de session a changé de nom : tout le monde se reconnecte une fois. La préférence de thème du navigateur est conservée.

Ce qu’il ne gère pas : le préfixe des métriques est passé de ezymonit_ à dumbmonit_ sans compatibilité. Les anciennes séries restent dans VictoriaMetrics sous l’ancien nom et disparaissent avec la rétention ; les graphiques et les règles intégrées repartent à partir de la mise à jour. Les règles d’alerte personnalisées qui citent des métriques ezymonit_… doivent être modifiées.

Sauvegarde et restauration

Un seul volume nommé, dumbmonit-data, contient tout :

Chemin	Contenu
dumbmonit.db	Surveillances, règles, canaux, état des alertes, sessions.
secret.key	Le secret de l’instance.
backups/	Les sauvegardes locales planifiées : une copie de la base et du secret, quotidienne par défaut, sept conservées.
vm/	Séries temporelles de VictoriaMetrics (12 mois de rétention par défaut).
vm-long/	Agrégats de 5 minutes, l’historique long (730 jours par défaut).
vlogs/	Données de VictoriaLogs, seulement si vous avez activé le stockage des journaux.

DumbMonit sauvegarde lui-même sa base selon un calendrier, et exporte toute la configuration — surveillances, identifiants, règles, canaux — dans un seul fichier chiffré avec une phrase secrète de votre choix, qui se restaure sur une instance vierge. Les deux sont décrits dans Sauvegarde et restauration, avec ce qu’il faut faire avant une mise à jour et l’unique règle sur secret.key qui mérite d’être lue deux fois.

Pour archiver le volume lui-même, graphiques compris, arrêtez la pile et archivez-le avec 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

Pour restaurer, créez le volume, extrayez-y l’archive de la même façon, puis docker compose up -d.

Si la place compte, --exclude=./vm garde l’archive petite : la base et le secret constituent la configuration, vm/ ne contient que les graphiques.

Options avancées

Le fichier Compose ci-dessus n’a volontairement aucune variable. Pour changer un réglage, ajoutez un bloc environment: (ou une ligne dedans) sous dumbmonit: dans votre docker-compose.yml, puis relancez docker compose up -d. Le conteneur est recréé ; le volume de données est conservé.

Un autre port. Changez la partie gauche du mappage ; le conteneur écoute toujours sur 8080 :

    ports:
      - "8099:8080"

Votre propre secret, à la place de celui généré dans /data/secret.key. Il chiffre les identifiants des surveillances : le perdre oblige à les ressaisir tous.

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

Rétention et mémoire du VictoriaMetrics embarqué (mois, ou 30d / 2y ; un homelab de quelques dizaines de surveillances tient dans 256 Mo) :

    environment:
      DUMBMONIT_VM_RETENTION: "24"
      DUMBMONIT_VM_MEMORY: 512MB

VictoriaMetrics externe ; l’embarqué n’est alors pas démarré :

    environment:
      DUMBMONIT_VM_URL: http://victoriametrics:8428

Mot de passe perdu. Ajoutez la ligne ci-dessous, lancez docker compose up -d, recréez le premier administrateur dans l’interface (surveillances, règles et canaux restent), puis retirez la ligne et relancez docker compose up -d une fois de plus :

    environment:
      DUMBMONIT_RESET_PASSWORD: "1"

Captures d’écran des changements de site web : un Chromium headless à côté du serveur ; voir Captures d’écran des changements de site web ci-dessous.

Plus de variables : référence de configuration.

Captures d’écran des changements de site web

La surveillance de changements de site web compare toujours le texte visible des pages. Conserver une capture d’écran de chaque nouvelle version demande un navigateur, que l’image DumbMonit n’embarque pas : un Chromium headless tourne comme second service, et DUMBMONIT_BROWSER_URL indique au serveur où le trouver.

Ajoutez ces lignes à votre docker-compose.yml, puis lancez 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 est le nom du service ; sur le réseau Compose, http://browser:9222 y mène. Rien ne publie son port : seul DumbMonit lui parle.
• shm_size: 256m : Chromium rend dans /dev/shm, et les 64 Mo par défaut de Docker sont trop peu pour une longue page.
• N’importe quel Chromium lancé avec --remote-debugging-port convient ; chromedp/headless-shell est l’image utilisée ici.

Sans navigateur, tout le reste fonctionne comme d’habitude (comparaison du texte, alertes, copies avant/après) ; les instantanés n’ont simplement pas d’image. Tant que le serveur n’atteint aucun navigateur, le formulaire d’une surveillance de changements de site web affiche un encart avec ces lignes. Si l’encart reste après le redémarrage, vérifiez docker compose logs browser, que le nom d’hôte de DUMBMONIT_BROWSER_URL est le nom du service, et que les deux services sont dans le même projet Compose.

Reverse proxy

L’interface et l’API sont servies sur un seul port, qui ne parle que HTTPS (une requête HTTP simple reçoit une redirection, voir HTTPS and encryption). Un reverse proxy doit donc se connecter au conteneur en HTTPS (https://dumbmonit:8080), avec la vérification du certificat désactivée pour ce saut ou le certificat de DumbMonit approuvé. Aucun WebSocket n’est utilisé : l’interface interroge l’API périodiquement, donc n’importe quel reverse proxy fonctionne sans configuration particulière.

Transmettez le schéma (X-Forwarded-Proto, envoyé d’office par Caddy et Traefik) et déclarez le proxy dans DUMBMONIT_TRUSTED_PROXIES : une requête qui porte des en-têtes transmis n’est jamais redirigée par DumbMonit lui-même, et depuis un proxy de confiance X-Forwarded-Proto: https rend le cookie de session Secure et active HSTS.

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;
        # Les agents envoient des lots de rattrapage après une panne :
        client_max_body_size 16m;
    }
}

Lorsque le proxy termine le TLS, définissez DUMBMONIT_COOKIE_SECURE: "1" pour que le cookie de session ne soit envoyé que par HTTPS. Ne le définissez que si chaque navigateur atteint DumbMonit en HTTPS : le navigateur ne renverrait jamais le cookie et la connexion serait impossible.

Agents derrière un proxy

La commande d’installation affichée lorsque vous créez un jeton d’agent utilise l’URL que votre navigateur a employée pour joindre l’interface. Si c’est l’URL du proxy, les agents l’utiliseront aussi : assurez-vous que /install.sh, /install.ps1, /download/… et /api/ingest passent bien par le proxy.

Permissions et répertoire de données

Le serveur ne s’exécute jamais sous root. Par défaut, l’image s’exécute sous l’utilisateur 65532:65532, auquel appartient déjà un volume nommé créé par Docker.

Un bind mount (./dumbmonit:/data) garde en revanche le propriétaire du répertoire de l’hôte, souvent root quand Docker l’a créé. C’est pourquoi le fichier Compose ci-dessus démarre le conteneur sous root (user: "0:0"). Le serveur ne le reste alors que le temps d’un instant : avant d’ouvrir la base, de lancer VictoriaMetrics ou d’écouter sur le réseau, il donne /data à 65532:65532 (uniquement les entrées qui appartiennent à quelqu’un d’autre, sans suivre les liens symboliques), abandonne root définitivement et vérifie qu’il ne peut pas le retrouver. Les quatre capabilities de cap_add ne servent qu’à cette étape ; aucune ne subsiste ensuite. no-new-privileges et le système de fichiers racine en lecture seule restent actifs : /data et /tmp sont les seuls chemins inscriptibles.

Choisir le propriétaire : PUID et PGID. Avec user: "0:0", indiquez l’uid et le gid sous lesquels le serveur s’exécute ; les fichiers leur sont transférés au démarrage :

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

DUMBMONIT_PUID / DUMBMONIT_PGID fonctionnent aussi et ont la priorité. 0 est refusé. Sur Unraid, PUID=99 et PGID=100 correspondent au propriétaire habituel d’appdata. Sans user: "0:0", PUID/PGID sont ignorés.

Sans user: "0:0" (un simple docker run -v ./data:/data, ou --user 1000:1000), aucun propriétaire ne change et /data doit déjà être inscriptible. Sinon, le serveur s’arrête et suggère d’abord --user 0:0, puis sudo chown -R 65532:65532 ./data sur l’hôte pour un bind mount, ou, pour un volume nommé :

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

SELinux et Podman

Sur un hôte où SELinux est en mode enforcing (Fedora, RHEL, CentOS Stream, AlmaLinux…), un bind mount est refusé au conteneur, root compris, tant qu’il ne porte pas d’étiquette de conteneur. Ajoutez :Z au volume, ou :z si d’autres conteneurs partagent le répertoire :

    volumes:
      - ./dumbmonit:/data:Z

Sans cela, le serveur s’arrête avec the host enforces SELinux and the volume has no container label. Les volumes nommés sont étiquetés par Docker et n’exigent rien.

Podman sans root fonctionne de la même façon, avec --user 0:0. Root dans le conteneur est votre propre utilisateur sur l’hôte, et les fichiers d’un bind mount vont à l’uid 65532 du conteneur, que l’hôte affiche comme l’un de vos sub-uids (165531 avec le /etc/subuid habituel). Lisez-les avec podman unshare ls -l ./dumbmonit. Pour les garder plutôt sous votre propre uid, exécutez le conteneur sous votre identité ; plus aucun propriétaire ne change alors :

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

Ping ICMP sans capability

La surveillance ping envoie des ICMP echo. Plutôt qu’un socket brut — qui demande NET_RAW, et une capability accordée à un utilisateur non root du conteneur n’est de toute façon pas utilisable — il emploie un socket ICMP echo, que Linux autorise pour les groupes listés dans net.ipv4.ping_group_range. Le fichier Compose définit ce sysctl dans l’espace de noms réseau propre au conteneur :

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

Rien ne change sur l’hôte. Docker 20.10 et les versions ultérieures définissent d’eux-mêmes cette plage dans chaque conteneur ; les lignes explicites la garantissent sur les moteurs plus anciens et sur Podman. Sans elle, la vérification signale une erreur de configuration (affichée sur la surveillance, sans notification), jamais un faux « hôte hors service ». Avec docker run, passez --sysctl net.ipv4.ping_group_range="0 2147483647". Tant que le serveur ne peut pas ouvrir de socket ICMP, le formulaire d’une surveillance ping affiche un encart avec ces lignes.

Tester sans matériel

Ajoutez une surveillance de démonstration : elle produit de fausses mesures sans rien à préparer, de sorte que les graphiques, règles et notifications peuvent être essayés immédiatement. Pour de vraies données SNMP, la machine qui fait tourner Docker suffit souvent — installez snmpd dessus (apt install snmpd, autorisez la communauté public sur le pont Docker dans /etc/snmp/snmpd.conf) et ajoutez un appareil SNMP avec l’adresse de l’hôte sur ce pont (172.17.0.1 par défaut) : le profil est détecté automatiquement et les interfaces, la mémoire et les processus apparaissent.

Les développeurs peuvent ajouter la surcouche docker-compose.dev.yml pour publier le VictoriaMetrics embarqué sur le :8428 de l’hôte pour des requêtes MetricsQL directes :

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