RustVpsMon : monitoring VPS léger pour TPE

Sur un petit VPS de TPE, le problème arrive rarement avec un grand signal visible.

Un disque se remplit parce que les logs Docker grossissent. Un conteneur s’arrête après un redémarrage. La RAM grimpe doucement après une mise à jour. Le site reste accessible une partie du temps, puis commence à répondre lentement. Personne ne regarde le serveur tous les matins. Et souvent, il n’y a pas de DSI pour maintenir une supervision complète.

RustVpsMon part de cette situation assez banale.

L’outil, développé par EloNeva, vise un besoin simple : surveiller un VPS sans installer une usine à gaz. CPU, RAM, disque, conteneurs Docker, historique local, alertes. Pas de cartographie complexe, pas de moteur de requêtes à apprendre, pas de dépendance frontend lourde. Un binaire Rust, une base SQLite, une interface web légère et des notifications.

C’est volontairement limité. Et c’est justement l’intérêt.

Dans une TPE, on ne cherche pas toujours à construire une supervision comparable à celle d’un hébergeur. On veut surtout savoir qu’un serveur va mal avant que le client appelle.

La réponse courte

RustVpsMon est un agent de monitoring léger pour VPS qui surveille les ressources système, les conteneurs Docker et les seuils critiques, avec des alertes e-mail ou webhook.

Il est adapté aux TPE qui hébergent quelques services sur un VPS : site vitrine, outil métier, reverse proxy, base de données légère, application interne, service Docker isolé.

Le projet repose sur une logique assez sobre :

• collecte des métriques hôte avec sysinfo,
• lecture des conteneurs Docker via bollard,
• stockage local en SQLite avec sqlx,
• interface web servie par Rust avec axum,
• mises à jour temps réel via SSE et HTMX,
• alertes anti-spam pour éviter de recevoir un message toutes les cinq secondes.

Ce n’est pas un remplacement de Prometheus, Grafana, Zabbix ou Netdata. Ce n’est pas non plus le but. RustVpsMon répond à un cas plus petit, plus fréquent qu’on ne le dit : un VPS unique qu’il faut garder sous surveillance sans y consacrer une demi-journée d’administration.

Pourquoi un outil aussi simple a du sens en TPE

Dans beaucoup de petites structures, l’infrastructure ressemble à ceci :

• un VPS chez un hébergeur,
• quelques conteneurs Docker,
• un reverse proxy,
• une base de données,
• une sauvegarde parfois documentée, parfois moins,
• une personne référente qui n’est pas administrateur système à temps plein.

On peut toujours installer une supervision complète. C’est possible. Mais ensuite il faut la maintenir, la sécuriser, l’expliquer, mettre à jour ses composants, comprendre ses alertes, nettoyer son stockage. Sur un seul VPS à 2 Go de RAM, ce n’est pas toujours raisonnable.

RustVpsMon prend une autre direction. Il accepte de faire peu de choses.

Il surveille les éléments qui cassent vraiment une petite production :

• le CPU,
• la RAM,
• le disque,
• l’état des conteneurs,
• les dépassements de seuils,
• le retour à la normale.

C’est moins impressionnant sur une capture d’écran. En exploitation, c’est souvent suffisant pour éviter les pannes les plus bêtes.

Définition : monitoring léger

Le monitoring léger consiste à surveiller un système avec un nombre réduit de composants, une configuration lisible et une empreinte mémoire faible.

Dans le cas de RustVpsMon, cela veut dire qu’on évite les briques séparées pour la collecte, le stockage, l’affichage et l’alerte. Le binaire embarque l’essentiel. SQLite garde l’historique local. Le dashboard est rendu côté serveur et mis à jour avec SSE.

Ce choix a une conséquence directe : l’outil se comprend vite.

Un dirigeant de TPE n’a pas besoin de savoir comment fonctionne tokio, axum ou bollard. Le responsable technique, lui, peut lire l’architecture sans devoir reconstituer cinq services différents.

Ce que RustVpsMon surveille réellement

Le README du projet annonce un agent tout-en-un pour VPS. Il surveille les ressources de l’hôte, découvre les conteneurs Docker, stocke un historique local et expose un dashboard web temps réel avec HTMX et SSE.

La partie hôte couvre les métriques classiques :

CPU global
RAM utilisée / RAM totale
Disque utilisé / disque total

La partie Docker s’appuie sur le socket Unix Docker. L’agent découvre les conteneurs en cours d’exécution et récupère leurs métriques. C’est pratique sur un VPS où les services sont déjà conteneurisés : application web, API, base, worker, reverse proxy.

La partie alerte est volontairement simple. Un seuil est dépassé, une alerte est créée. Si le problème reste présent, l’outil ne renvoie pas une notification à chaque cycle. Il garde un état d’incident. C’est un détail important sur un petit serveur, parce qu’une alerte bruyante devient vite ignorée.

Exemple typique :

RAM > 90 %
Alerte créée
Webhook envoyé
Incident déjà connu au cycle suivant
Aucune nouvelle notification
Retour sous le seuil
Notification de retour à la normale

Ce comportement vaut mieux qu’un outil qui déclenche 300 e-mails pendant la nuit.

Architecture retenue

L’architecture de RustVpsMon est assez lisible.

Le point intéressant n’est pas seulement Rust. C’est l’assemblage.

Pas de serveur Node pour l’interface. Pas de base distante obligatoire. Pas de broker. Pas de stack de dashboard externe. Le dashboard existe parce que le binaire le sert. L’historique existe parce que SQLite suffit.

Pour une TPE, cette sobriété réduit les points de panne. Elle réduit aussi ce qu’il faudra expliquer six mois plus tard.

Installer RustVpsMon sur Ubuntu Server

Les commandes ci-dessous partent d’une base Ubuntu Server 24.x. Elles restent volontairement simples. Sur une machine de production, on adaptera les chemins, l’utilisateur de service et la politique de sauvegarde.

Préparer le serveur

sudo apt update
sudo apt install -y \
  ca-certificates \
  curl \
  git \
  build-essential \
  pkg-config \
  libssl-dev \
  sqlite3

Installer Rust avec rustup :

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
. "$HOME/.cargo/env"

rustc --version
cargo --version

Sur un serveur client, je préfère compiler sur une machine de build et déployer uniquement le binaire. Mais pour un premier test interne, compiler directement sur le VPS permet de valider vite.

Construire le binaire

cd /opt
sudo git clone https://github.com/LG-IsiNeva/RustVpsMon.git rustvpsmon
sudo chown -R "$USER:$USER" /opt/rustvpsmon

cd /opt/rustvpsmon
cargo build --release

Le nom exact du binaire dépend du Cargo.toml. Dans les exemples qui suivent, on utilise rustvpsmon. Si le projet génère un autre nom, il faut l’adapter.

sudo mkdir -p /usr/local/bin /var/lib/rustvpsmon /etc/rustvpsmon
sudo install -m 0755 target/release/rustvpsmon /usr/local/bin/rustvpsmon

Configuration minimale

RustVpsMon lit sa configuration depuis l’environnement ou un fichier .env. Toutes les variables sont préfixées RUSTMON_.

Exemple de fichier /etc/rustvpsmon/rustvpsmon.env :

RUSTMON_BIND_ADDR=127.0.0.1:3000
RUSTMON_DB_PATH=/var/lib/rustvpsmon/data.db
RUSTMON_DISK_PATH=/
RUSTMON_SAMPLE_INTERVAL_SECS=10
RUSTMON_RETENTION_DAYS=14

RUSTMON_CPU_THRESHOLD_PCT=90.0
RUSTMON_RAM_THRESHOLD_PCT=90.0
RUSTMON_DISK_THRESHOLD_PCT=85.0

RUSTMON_WEBHOOK_URL=https://example.invalid/webhook

Quelques remarques terrain.

RUSTMON_BIND_ADDR=127.0.0.1:3000 évite d’exposer directement le dashboard sur Internet. On le placera derrière Traefik, Nginx ou un accès VPN. Sur un VPS de TPE, une interface de monitoring ouverte publiquement finit souvent par devenir une mauvaise surprise.

RUSTMON_RETENTION_DAYS=14 suffit généralement pour diagnostiquer une dérive récente. Garder des mois de métriques locales sur un petit disque n’apporte pas grand-chose.

RUSTMON_DISK_THRESHOLD_PCT=85.0 est plus prudent que 90 % sur certains VPS. Entre les logs, les images Docker et les sauvegardes temporaires, les derniers gigaoctets partent vite.

Lancer RustVpsMon avec systemd

Pour un service simple, systemd reste le bon choix. Le service redémarre si le binaire tombe, démarre au boot et se consulte avec journalctl.

Créer un utilisateur dédié :

sudo useradd \
  --system \
  --home /var/lib/rustvpsmon \
  --shell /usr/sbin/nologin \
  rustvpsmon

sudo chown -R rustvpsmon:rustvpsmon /var/lib/rustvpsmon
sudo chmod 750 /var/lib/rustvpsmon

Si RustVpsMon doit lire Docker, l’utilisateur doit accéder au socket Docker. C’est un choix à traiter sérieusement. Être membre du groupe docker donne des capacités très larges sur l’hôte.

sudo usermod -aG docker rustvpsmon

Créer /etc/systemd/system/rustvpsmon.service :

[Unit]
Description=RustVpsMon lightweight VPS monitoring
After=network-online.target docker.service
Wants=network-online.target

[Service]
Type=simple
User=rustvpsmon
Group=rustvpsmon
SupplementaryGroups=docker
EnvironmentFile=/etc/rustvpsmon/rustvpsmon.env
WorkingDirectory=/var/lib/rustvpsmon
ExecStart=/usr/local/bin/rustvpsmon
Restart=on-failure
RestartSec=5

NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/rustvpsmon

[Install]
WantedBy=multi-user.target

Activer le service :

sudo systemctl daemon-reload
sudo systemctl enable --now rustvpsmon
sudo systemctl status rustvpsmon --no-pager

Lire les logs :

sudo journalctl -u rustvpsmon -f

Tester localement :

curl -I http://127.0.0.1:3000

Ce service n’est pas parfait pour tous les cas. Il donne une base propre : pas de lancement manuel, pas de session SSH qui garde le process en vie, pas de script oublié dans un screen.

Variante Docker Compose

Le README du projet fournit un démarrage Docker Compose. C’est cohérent quand le VPS héberge déjà ses services dans Docker.

Exemple d’ossature :

services:
  rustvpsmon:
    build: .
    container_name: rustvpsmon
    restart: unless-stopped
    env_file:
      - .env
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /:/host:ro
      - ./data:/app/data
    environment:
      RUSTMON_BIND_ADDR: "0.0.0.0:3000"
      RUSTMON_DISK_PATH: "/host"
      RUSTMON_DB_PATH: "/app/data/data.db"

Le montage /var/run/docker.sock permet la découverte des conteneurs. Le montage /host en lecture seule sert à mesurer le disque réel de l’hôte plutôt que le disque vu depuis le conteneur.

Là encore, le socket Docker n’est pas un détail anodin. Même en lecture seule côté montage, il faut considérer l’accès au daemon Docker comme sensible.

Utiliser Docker secrets pour les identifiants SMTP

RustVpsMon lit sa configuration via variables d’environnement. Pour éviter de stocker un mot de passe SMTP directement dans .env, on peut utiliser un secret Docker et un petit point d’entrée qui exporte la variable attendue.

Exemple :

services:
  rustvpsmon:
    build: .
    container_name: rustvpsmon
    restart: unless-stopped
    env_file:
      - .env
    secrets:
      - rustmon_smtp_password
    entrypoint:
      - /bin/sh
      - -c
      - |
        export RUSTMON_SMTP_PASSWORD="$$(cat /run/secrets/rustmon_smtp_password)"
        exec /app/rustvpsmon
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /:/host:ro
      - ./data:/app/data
    ports:
      - "127.0.0.1:3000:3000"

secrets:
  rustmon_smtp_password:
    file: ./secrets/rustmon_smtp_password

Fichier .env associé :

RUSTMON_SMTP_HOST=smtp.example.com
RUSTMON_SMTP_PORT=587
RUSTMON_SMTP_USER=monitoring@example.com
RUSTMON_EMAIL_FROM=monitoring@example.com
RUSTMON_EMAIL_TO=admin@example.com

Création du secret local :

mkdir -p secrets
printf '%s' 'mot-de-passe-smtp-long' > secrets/rustmon_smtp_password
chmod 600 secrets/rustmon_smtp_password

Ce pattern suppose que l’image contient /bin/sh. Si l’image finale est construite FROM scratch, il faudra soit ajouter la lecture du secret côté application, soit utiliser une image minimale avec shell. C’est un choix de build, pas une règle universelle.

Exposer le dashboard sans l’ouvrir au monde

Le dashboard doit rester accessible aux personnes concernées, pas à Internet entier.

Sur un VPS déjà équipé de Traefik, on peut exposer RustVpsMon derrière un routeur HTTPS, avec authentification en amont ou restriction IP. Le sujet rejoint directement les pratiques abordées dans l’article sur Traefik comme reverse proxy .

Exemple Nginx minimal pour un accès derrière authentification ou VPN :

server {
    listen 443 ssl http2;
    server_name monitoring.example.com;

    ssl_certificate     /etc/letsencrypt/live/monitoring.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/monitoring.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_buffering off;
    }
}

proxy_buffering off évite des comportements gênants avec les flux SSE. Sans ça, les mises à jour temps réel peuvent sembler figées selon la configuration.

Sur une TPE, je préfère souvent commencer avec une restriction IP ou un accès VPN. Une authentification HTTP basique peut dépanner, mais elle ne doit pas devenir la seule barrière si l’interface expose des informations sensibles sur la production.

Choisir les bons seuils

Les seuils par défaut à 90 % sont compréhensibles. En production, je les ajuste presque toujours.

Un VPS avec 2 Go de RAM peut devenir instable bien avant que l’alerte ne soit visible par un humain. Un disque à 90 % peut passer à 100 % en quelques minutes si un export, une sauvegarde ou un log dérape.

Exemple de réglage plus prudent :

RUSTMON_CPU_THRESHOLD_PCT=95.0
RUSTMON_RAM_THRESHOLD_PCT=85.0
RUSTMON_DISK_THRESHOLD_PCT=80.0
RUSTMON_SAMPLE_INTERVAL_SECS=10
RUSTMON_RETENTION_DAYS=14

Le CPU peut monter haut ponctuellement. Ce n’est pas toujours grave. La RAM et le disque demandent moins de tolérance, surtout sur un serveur qui héberge une base de données ou des conteneurs applicatifs.

Pour une TPE, une alerte utile doit être rare et compréhensible. Si elle sonne tous les jours, elle finit dans un coin de boîte mail.

Ce que RustVpsMon ne cherche pas à faire

Il faut être clair sur les limites.

RustVpsMon n’est pas une plateforme multi-tenant. Il ne remplace pas une supervision distribuée sur 20 serveurs. Il ne fournit pas une analyse longue période avec tableaux complexes. Il ne centralise pas les métriques de plusieurs clients. Il ne remplace pas une politique de sauvegarde.

Il surveille un VPS. Il le fait avec peu de dépendances.

Pour une entreprise qui commence à structurer son infrastructure, c’est souvent une étape saine. On met d’abord un voyant fiable sur le serveur. Ensuite seulement, si le parc grandit, on bascule vers une supervision centralisée.

C’est la même logique que pour une suite collaborative souveraine destinée aux TPE : le bon outil n’est pas forcément celui qui couvre le plus de cases. C’est celui qui correspond à la charge réelle de l’entreprise.

Points de sécurité à ne pas négliger

Un outil léger n’autorise pas une configuration légère côté sécurité.

Le premier point concerne Docker. L’accès au socket /var/run/docker.sock est puissant. Si l’interface RustVpsMon ou le process est compromis, l’impact peut dépasser la simple lecture des métriques. Il faut limiter l’exposition réseau du dashboard, tenir le serveur à jour et éviter les comptes partagés.

Le deuxième point concerne les secrets. Un webhook ou un mot de passe SMTP n’a rien à faire dans un dépôt Git. En Docker, on utilisera des secrets. En systemd, on peut stocker le fichier d’environnement avec des droits stricts :

sudo chown root:rustvpsmon /etc/rustvpsmon/rustvpsmon.env
sudo chmod 640 /etc/rustvpsmon/rustvpsmon.env

Le troisième point concerne la rétention. Une base SQLite alimentée toutes les quelques secondes doit être purgée. RustVpsMon prévoit une rétention configurable. Il faut la régler. Un outil de monitoring qui remplit le disque qu’il surveille, c’est une panne assez agaçante à expliquer.

Cas d’usage réel : le VPS qui héberge trois services

Prenons un cas courant.

Une TPE héberge sur un VPS :

• un site web,
• une petite API,
• un PostgreSQL ou MariaDB conteneurisé,
• Traefik en reverse proxy,
• un job de sauvegarde nocturne.

Le serveur fonctionne bien. Il n’y a pas de monitoring. Les sauvegardes écrivent dans un dossier local avant transfert. Un soir, le transfert échoue. Les archives restent sur disque. Deux jours plus tard, le disque passe à 100 %. La base refuse certaines écritures. Le site commence à répondre de manière irrégulière.

RustVpsMon ne résout pas la cause. Il évite de la découvrir trop tard.

Avec un seuil disque à 80 %, une alerte webhook part vers un canal interne. Quelqu’un peut se connecter, vérifier les sauvegardes, supprimer les archives temporaires, corriger le job. C’est basique. C’est exactement ce qu’il fallait.

Où le placer dans une trajectoire EloNeva

Chez EloNeva, RustVpsMon s’inscrit dans une approche plus large : rendre les petites infrastructures plus lisibles sans les suréquiper.

Une TPE n’a pas toujours besoin d’un chantier DevOps complet. Elle a besoin de savoir ce qui tourne, où sont les risques, quels signaux doivent déclencher une réaction. C’est proche de ce qu’on observe dans les projets informatiques de TPE qui peinent à produire des résultats visibles : l’outil compte, mais le niveau d’exploitation compte autant.

RustVpsMon donne une première couche de visibilité. Elle peut ensuite être complétée par :

• une sauvegarde testée,
• une politique de mises à jour,
• une restriction d’accès au dashboard,
• une documentation courte du VPS,
• un contrôle des logs Docker,
• une vérification périodique des certificats.

Rien de spectaculaire. Juste de quoi éviter qu’un petit serveur devienne un point aveugle.

Conclusion

RustVpsMon est intéressant parce qu’il ne cherche pas à impressionner.

Il surveille un VPS, ses ressources, ses conteneurs et ses seuils critiques. Il garde un historique local. Il alerte sans spammer. Il reste léger en mémoire. Pour une TPE, c’est souvent plus utile qu’une stack complète installée trop vite et jamais vraiment maintenue.

Le bénéfice métier est simple : réduire les pannes silencieuses sur les petits serveurs qui portent parfois des services importants.

Pour EloNeva, ce type d’outil a du sens dans les environnements sobres : un VPS, quelques conteneurs, une responsabilité claire, des alertes compréhensibles. Pas de fioriture. Pas de promesse excessive. Juste un voyant fiable là où il en manquait un.