Surveiller Proxmox VE, PBS et Docker avec Pulse sur un serveur dédié : alertes Discord et Telegram

Pulse : un tableau de bord de supervision pour Proxmox VE, PBS et Docker

Pulse est un outil de supervision (monitoring) open source sous licence MIT, développé par rcourtman sur GitHub. Sa version 6.7.0 est sortie le 2 novembre 2026 et le dépôt dépasse les 7 000 étoiles. Le principe : un seul tableau de bord léger qui affiche l'état de votre hyperviseur Proxmox VE (nœuds, machines virtuelles, conteneurs LXC, stockage, sauvegardes, réplication, Ceph), de votre Proxmox Backup Server (datastores, tâches de sauvegarde, vérification, garbage collection), de Proxmox Mail Gateway (statistiques mail, files d'attente, quarantaine), de vos hôtes Docker ou Podman (conteneurs, projets Compose, services Swarm, état de santé, mises à jour d'images), de Kubernetes, de TrueNAS SCALE et CORE, et des serveurs Linux, Windows ou macOS via un agent. Pulse ajoute des vérifications de disponibilité (ping, TCP, UDP, HTTP et HTTPS avec alerte d'expiration de certificat) et un moteur d'alertes qui notifie sur Discord, Telegram, Slack, Teams, ntfy, Gotify, Pushover, PagerDuty, par e-mail ou vers n'importe quel webhook.

Deux modes de collecte coexistent. Proxmox VE, PBS, PMG et TrueNAS sont interrogés par leur API avec un token en lecture seule : aucun agent à installer sur l'hôte. Docker, Kubernetes et les machines autonomes passent par l'agent pulse-agent, un binaire Go unique qui remonte ses mesures vers le serveur Pulse. L'édition Community, celle du dépôt GitHub, est gratuite et conserve 7 jours d'historique de métriques. Une édition Pro payante ajoute 90 jours d'historique, le RBAC et la journalisation d'audit, mais tout ce que décrit ce guide fonctionne avec l'édition gratuite.

Pour l'administrateur d'un serveur dédié sous Proxmox VE qui héberge une quinzaine de VM et de conteneurs, le gain est concret : savoir qu'une sauvegarde a échoué le jour même et non le jour où il faut la restaurer, être prévenu qu'un disque virtuel approche de la saturation, ou qu'un conteneur Docker tourne en état unhealthy depuis une heure. Ce guide couvre l'installation de Pulse dans un conteneur LXC sur l'hôte Proxmox, la création du token API, le raccordement de PBS, l'ajout de l'agent sur les hôtes Docker et les VM Linux, la configuration des alertes et des notifications Discord et Telegram, puis la mise en garde du projet sur les requêtes QEMU Guest Agent pendant les sauvegardes.

Prérequis

• Un serveur dédié sous Proxmox VE 8 ou 9, à jour (voir sécuriser et mettre à jour Proxmox VE), avec un accès root en SSH sur l'hôte ;
• Sur l'hôte : bash, curl et ssh-keygen (paquet OpenSSH) pour vérifier la signature de l'installeur ;
• Facultatif : un Proxmox Backup Server joignable en HTTPS sur le port 8007, et un ou plusieurs hôtes Docker (VM, conteneur LXC ou VPS avec Docker) ;
• Un serveur Discord sur lequel vous avez la permission de gérer les webhooks, et/ou un compte Telegram ;
• Un navigateur pour l'interface web de Pulse, servie sur le port 7655.

Installer Pulse dans un conteneur LXC sur l'hôte Proxmox

Le projet distribue un installeur signé. Exécuté sur l'hôte Proxmox VE, il crée et configure lui-même un conteneur LXC léger dédié à Pulse. Le bloc ci-dessous, à coller d'un seul tenant dans un shell root sur l'hôte, épingle la version, télécharge le script et sa signature depuis la page de release GitHub, vérifie la signature ed25519 avec ssh-keygen -Y verify contre la clé publique du projet (identité pulse-installer, espace de noms pulse-install), et ne lance l'installation que si la vérification réussit :

export PULSE_VERSION=v6.7.0
curl -fsSLO "https://github.com/rcourtman/Pulse/releases/download/${PULSE_VERSION}/install.sh" &&
curl -fsSLO "https://github.com/rcourtman/Pulse/releases/download/${PULSE_VERSION}/install.sh.sshsig" &&
ssh-keygen -Y verify \
  -f <(printf '%s\n' 'pulse-installer namespaces="pulse-install" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMZd/DaH+BldzOkq1A8KVTcFk73nAyrE8aJOyf7i00jm pulse-installer') \
  -I pulse-installer \
  -n pulse-install \
  -s install.sh.sshsig < install.sh &&
bash install.sh --version "${PULSE_VERSION}"

Si un téléchargement ou la vérification de signature échoue, le projet demande de ne pas relancer la dernière ligne seule pour contourner l'erreur. Vérifiez d'abord avec pct list qu'un conteneur partiellement créé ne traîne pas, puis recommencez le bloc complet. À la fin, l'installeur affiche la commande qui récupère le jeton d'amorçage (bootstrap token), avec l'identifiant du conteneur qu'il vient de créer :

pct exec <ctid> -- /usr/local/bin/pulse bootstrap-token

Ouvrez ensuite http://<ip-du-conteneur>:7655, collez ce jeton et suivez l'assistant « Quick Security Setup » : il crée le compte administrateur et affiche un token API Pulse. Conservez les deux dans votre gestionnaire de mots de passe, l'interface ne les réaffichera pas. Pour mettre à jour plus tard, l'installeur dépose un utilitaire /bin/update dans le conteneur, à lancer après une sauvegarde du répertoire de données. Si vous aviez déployé Pulse via les scripts communautaires décrits dans notre guide Proxmox VE Helper Scripts, sachez que le projet signale que le /bin/update de ces conteneurs n'est pas le sien et ignore l'option --version.

Alternative : Pulse en conteneur Docker sur le port 7655

Si vous préférez héberger Pulse hors de l'hyperviseur, par exemple sur un VPS Linux qui supervise plusieurs serveurs dédiés, l'image officielle rcourtman/pulse s'installe en une commande. Le conteneur n'a pas besoin du socket Docker : les hôtes Docker sont supervisés par l'agent, pas par le serveur Pulse. Épinglez une version précise plutôt que latest, comme le recommande la documentation de sécurité du projet :

docker run -d \
  --name pulse \
  -p 7655:7655 \
  -v pulse_data:/data \
  -e PULSE_DEPLOYMENT_METHOD=docker_run \
  --restart unless-stopped \
  rcourtman/pulse:v6.7.0

L'équivalent en fichier compose.yaml, si vous gérez vos services avec Docker Compose :

services:
  pulse:
    image: rcourtman/pulse:v6.7.0
    container_name: pulse
    restart: unless-stopped
    ports:
      - "7655:7655"
    volumes:
      - pulse_data:/data
    environment:
      - PULSE_DEPLOYMENT_METHOD=docker_compose

volumes:
  pulse_data:

Le jeton d'amorçage se récupère avec docker exec pulse /app/pulse bootstrap-token. Les données (configuration, identifiants chiffrés, historique) vivent dans le volume monté sur /data, là où l'installation LXC ou systemd utilise /etc/pulse. Pour arrêter ou supprimer le conteneur, n'ajoutez jamais l'option -v à docker rm : le volume contient la clé de chiffrement des identifiants.

Créer un token API Proxmox VE en lecture seule

Pulse ne doit jamais utiliser root@pam. La bonne pratique est un utilisateur dédié, un token API à privilèges séparés (privsep) et le rôle intégré PVEAuditor, qui donne un accès en lecture seule. Avec la séparation des privilèges, les permissions effectives du token sont l'intersection de celles de l'utilisateur et de celles du token : il faut donc poser l'ACL sur les deux. Sur l'hôte Proxmox :

pveum user add pulse-monitor@pve -comment "Supervision Pulse"
pveum user token add pulse-monitor@pve pulse-readonly -privsep 1
pveum acl modify / -user pulse-monitor@pve -role PVEAuditor
pveum acl modify / -token 'pulse-monitor@pve!pulse-readonly' -role PVEAuditor

La deuxième commande affiche le secret du token une seule fois. Notez-le immédiatement : il ne se saisit que dans le champ « Token Value » de Pulse, jamais dans une URL ni dans une commande partagée. Le rôle PVEAuditor regroupe les privilèges d'audit de chaque catégorie, dont Sys.Audit et Datastore.Audit qui couvrent l'inventaire, les métriques des nœuds et le contenu des stockages, donc la liste des sauvegardes vzdump.

Point important pour la suite : sur Proxmox VE 9, PVEAuditor contient aussi VM.GuestAgent.Audit, le privilège qui autorise les commandes informatives vers le QEMU Guest Agent. C'est lui qui permet à Pulse de lire l'usage disque à l'intérieur des VM, et c'est lui qui est en cause dans la mise en garde sur les sauvegardes, traitée plus bas. Sur Proxmox VE 8, Pulse s'appuie sur le privilège VM.Monitor pour la même lecture. La lecture de la mémoire d'une VM Linux via /proc/meminfo demande en plus VM.GuestAgent.FileRead, que PVEAuditor n'inclut pas ; le projet conseille plutôt d'installer son agent dans la VM pour obtenir cette donnée.

Pulse propose aussi un script de configuration généré depuis « Settings → Infrastructure → Add infrastructure → Proxmox VE ». Il crée un compte pulse-monitor avec les ACL de supervision ; le token est saisi à une invite silencieuse et jamais dans l'URL, et le lien généré expire au bout de cinq minutes. Relisez le script avant de l'exécuter sur un hyperviseur de production. Dans les deux cas, l'ajout du nœud se fait dans cette même page : adresse https://<ip-hote>:8006, authentification « API Token », identifiant pulse-monitor@pve!pulse-readonly, secret, et vérification TLS activée. Avec le certificat auto-signé par défaut de Proxmox, renseignez l'empreinte SHA-256 relevée directement sur l'hôte, pas celle que vous propose une connexion en échec :

openssl x509 -in /etc/pve/local/pve-ssl.pem -noout -fingerprint -sha256

Connecter Proxmox Backup Server

Le raccordement de PBS suit la même logique, avec le rôle Audit accordé à l'utilisateur et au token, puisque PBS limite lui aussi les permissions d'un token à celles de son propriétaire. Sur le serveur de sauvegarde :

proxmox-backup-manager user create pulse-monitor@pbs --comment "Pulse monitoring"
proxmox-backup-manager user generate-token pulse-monitor@pbs pulse-token
proxmox-backup-manager acl update / Audit --auth-id pulse-monitor@pbs
proxmox-backup-manager acl update / Audit --auth-id 'pulse-monitor@pbs!pulse-token'

Dans Pulse, choisissez « Proxmox Backup Server », l'adresse https://<ip-pbs>:8007, « API Token » puis « Manual Token Setup », avec l'identifiant pulse-monitor@pbs!pulse-token. L'empreinte du certificat se relève sur PBS avec openssl x509 -in /etc/proxmox-backup/proxy.pem -noout -fingerprint -sha256. Après le test de connexion, vérifiez que les datastores et les groupes de sauvegarde attendus apparaissent bien : un test réussi prouve l'authentification, pas la visibilité de chaque datastore.

Le tableau de bord affiche alors l'occupation des datastores et leurs namespaces, les groupes et instantanés avec leur propriétaire, l'état des tâches de synchronisation, de vérification, de prune et de garbage collection, le facteur de déduplication et la santé du serveur PBS (CPU, mémoire, uptime). Le projet le rappelle : une vérification réussie est une preuve sur une sauvegarde précise, pas une preuve de restauration. Les tests de restauration restent à planifier à part. Pour Proxmox Mail Gateway, enfin, le formulaire actuel utilise un compte de service avec mot de passe (par exemple pulse-monitor@pmg) et non un token ; si vous avez suivi notre guide Proxmox Mail Gateway sur serveur dédié, créez-lui un compte avec les seuls droits de lecture.

Ajouter l'agent Pulse sur les hôtes Docker et les VM Linux

Proxmox VE et PBS se passent d'agent, mais Docker, Podman, Kubernetes et les machines autonomes en ont besoin. L'agent unifié s'installe comme service systemd pulse-agent, envoie ses rapports vers le serveur Pulse toutes les 30 secondes par défaut (option --interval) et n'expose qu'un point de santé local sur 127.0.0.1:9191. C'est un émetteur sortant : aucun port entrant à ouvrir sur l'hôte supervisé, seul le serveur Pulse doit être joignable, idéalement en HTTPS.

La procédure officielle part de l'interface : « Settings → Infrastructure → Install on a host ». Pulse génère un token d'agent (laissez décochée l'option « Allow Pulse to run commands on this host », qui donne un droit d'exécution équivalent à root) et une commande à copier sur l'hôte. Cette commande télécharge l'installeur servi par votre propre serveur Pulse sur /install.sh, lance une vérification préalable, puis demande le token à une invite privée : il n'apparaît ni dans l'historique du shell ni dans la liste des processus. La forme manuelle équivalente, avec le token stocké dans un fichier en mode 600 :

bash "$HOME/.config/pulse/agent-install.sh" \
  --url https://pulse.example.com \
  --token-file "$HOME/.config/pulse/agent-token"

Sur un hôte Docker, l'agent détecte le runtime et active de lui-même le module Docker ; forcez-le avec --enable-docker, limitez-vous aux conteneurs avec --enable-host=false --enable-docker, ou choisissez Podman avec --docker-runtime podman. Il remonte l'inventaire des conteneurs, leur état et leur santé, la consommation CPU et mémoire, les projets Compose et services Swarm, et compare les digests des images en cours d'exécution aux tags du registre pour signaler les mises à jour disponibles. L'exécution de commandes (démarrer, arrêter, mettre à jour un conteneur depuis l'interface) est désactivée par défaut (--enable-commands à false) : la supervision n'en a pas besoin.

Par défaut l'agent Linux tourne en root pour accéder à S.M.A.R.T., aux températures et au socket Docker. L'option --least-privilege le fait tourner sous un utilisateur système pulse-agent, ajouté au groupe docker quand la supervision Docker est active ; le projet rappelle que ce groupe équivaut à root face à un démon Docker classique. Deux cas méritent l'agent en plus de l'API Proxmox : une VM Linux, où l'agent fournit la mémoire et les systèmes de fichiers sans passer par le QEMU Guest Agent, et un conteneur LXC qui héberge Docker, où l'agent doit être installé à l'intérieur du conteneur. La découverte de Docker dans les LXC depuis l'hôte via pct exec existe, mais elle est désactivée par défaut et remonte moins d'informations.

Configurer les alertes : sauvegarde en échec, disque plein, conteneur unhealthy, nœud hors ligne

Les règles se définissent dans « Alerts → Thresholds » et sont enregistrées dans alerts.json. Chaque seuil d'usage a une valeur de déclenchement et une valeur de retour à la normale (hystérésis) : avec un seuil CPU réglé à 90 % de déclenchement et 80 % de retour, une VM qui oscille entre 85 et 92 % ne génère pas une rafale d'alertes. Des délais d'activation et de rétablissement s'ajoutent, et une métrique se désactive avec son interrupteur On/Off, jamais en vidant le champ : une valeur vide hérite du défaut du groupe, et zéro ne signifie pas « alerter sur tout usage ».

• Disque plein : seuils d'usage disque sur les nœuds, les VM et les conteneurs, avec surcharges par ressource. Un stockage ZFS qui dépasse 80 % ou un disque virtuel de base de données à 90 % remontent avant la panne, ce qui complète les commandes manuelles de notre guide surveiller l'espace disque.
• Sauvegarde en échec ou trop ancienne : dans « Alerts → Thresholds → Proxmox → Recovery », les champs « Warning Days » et « Critical Days » déclenchent une alerte quand la dernière sauvegarde réussie d'un invité dépasse l'âge fixé. Une tâche vzdump ou PBS en erreur apparaît en outre dans la vue des sauvegardes. Pendant une sauvegarde active, Pulse diffère l'alerte d'arrêt d'un invité, mais seulement tant qu'il dispose d'une preuve fraîche que la sauvegarde tourne, et avec un plafond : une sauvegarde bloquée ne masque pas une panne.
• Conteneur unhealthy : chaque conteneur Docker a ses alertes de seuil (état, santé, ressources) et une alerte « Offline » distincte, chacune désactivable séparément. Le runtime a sa propre alerte hors ligne, qui ne couvre pas ses conteneurs.
• Nœud hors ligne : quand un hôte ne répond plus, l'alerte « host offline » porte seule l'incident, sans doubler chaque vérification de disponibilité qui échoue sur cette machine.

Côté bruit, le cooldown fixe l'intervalle minimal en minutes entre deux rappels d'une même alerte, une limite horaire plafonne les notifications ordinaires par couple ressource/métrique, et les alertes se regroupent dans une fenêtre configurable. Les heures calmes (quiet hours) sont désactivées par défaut ; activées, elles retiennent les notifications non critiques dans le fuseau horaire choisi, les critiques continuant de passer sauf suppression explicite. Une alerte s'acquitte (plus de rappel ni d'escalade jusqu'à résolution) ou se met en sommeil (snooze) jusqu'à une heure donnée. Enfin, chaque destination de notification filtre par sévérité minimale et par tags de ressources : on peut envoyer tout sur Discord et réserver Telegram aux alertes critiques.

Envoyer les notifications sur Discord et Telegram

Les destinations se configurent dans « Alerts → Notifications → Add Webhook ». Cliquez sur l'étiquette du service (« Generic » par défaut) pour choisir le type, collez l'URL, enregistrez et utilisez le bouton « Test ». Le projet précise qu'un test réussi ne garantit pas la livraison des vraies alertes : validez avec un seuil volontairement bas sur une VM de test.

Discord. Dans votre serveur, ouvrez « Paramètres du serveur → Intégrations → Webhooks → Nouveau webhook » (ou « Modifier le salon → Intégrations » depuis le salon cible), choisissez le salon, nommez le webhook « Pulse » et copiez son URL. Elle a la forme https://discord.com/api/webhooks/{id}/{token} ; quiconque la détient peut écrire dans le salon, traitez-la comme un mot de passe. Dans Pulse, type « Discord », collez l'URL : aucun autre champ n'est requis.

Telegram. Créez un bot auprès de BotFather avec la commande /newbot ; vous recevez un token de la forme 4839574812:AAFD39kkdpWt3ywyRZergyOLMaJhac60qc (exemple de la documentation Telegram). Envoyez un message au bot, ou ajoutez-le à un groupe d'astreinte, puis ouvrez https://api.telegram.org/bot<token>/getUpdates dans un navigateur : l'identifiant à retenir est le champ id de l'objet chat. Dans Pulse, type « Telegram », URL https://api.telegram.org/bot{bot_token}/sendMessage?chat_id={chat_id} : Pulse lit le chat_id dans la chaîne de requête et remplit lui-même le corps du message.

Les autres canaux suivent le même schéma : https://ntfy.sh/{topic} pour ntfy (sélectionnez bien « ntfy » dans le sélecteur), https://gotify.example.com/message?token={token} pour Gotify, et pour Pushover l'URL https://api.pushover.net/1/messages.json avec token et user en champs personnalisés. Un webhook générique accepte un gabarit JSON en syntaxe de templates Go ({{.Level}}, {{.ResourceName}}, {{.Message}}, {{.AlertURL}}) et peut signer ses requêtes en HMAC via un signingSecret (en-têtes X-Pulse-Signature et X-Pulse-Timestamp). Deux pièges fréquents : les adresses IP privées sont bloquées par défaut pour les webhooks, à autoriser dans « Settings → System → Network → Webhook Security » si votre ntfy ou votre Gotify tourne sur le réseau local ; et PULSE_PUBLIC_URL doit pointer vers l'adresse publique de Pulse pour que les liens dans les notifications s'ouvrent depuis votre téléphone.

La mise en garde du projet : QEMU Guest Agent et sauvegardes avec freeze

Le README de Pulse le formule ainsi : « API-only does not mean guest-agent-free ». Pour lire l'usage des systèmes de fichiers à l'intérieur d'une VM, Pulse demande à l'API Proxmox d'interroger le QEMU Guest Agent installé dans l'invité. Or ce canal est le même que celui qu'utilise vzdump pendant une sauvegarde en mode snapshot : le gel (freeze) puis le dégel (thaw) des systèmes de fichiers passent par l'agent invité. Un ticket GitHub décrit une VM restée gelée alors que la tâche de sauvegarde s'était terminée en OK. Dans la reproduction menée par le projet, une requête d'agent envoyée pendant un gel lent a fait échouer le dégel avec l'erreur got wrong command id, pendant que la tâche continuait d'afficher OK. Les invités se sont dégelés à chaque essai et la cause du gel signalé n'est pas établie, mais la conclusion du projet est claire : un rapport de sauvegarde OK ne prouve pas un dégel réussi.

Pulse suspend ses lectures via l'agent invité tant que Proxmox signale un verrou (lock) sur la VM, et jusqu'à la première heure d'une tâche de réplication. Il ne peut pas détecter un gel sans verrou, comme lors d'un clonage ou d'un import de disque, et une lecture déjà en cours au moment où le gel démarre peut encore provoquer l'erreur. Les consignes du projet, à respecter sur un serveur dédié de production :

• Ne jamais envoyer de sonde manuelle (qm agent) pendant une sauvegarde, un gel ou un dégel, et ne pas tester le freeze/thaw comme diagnostic ;
• Ne pas élargir les permissions, ne pas installer, activer ou redémarrer l'agent invité juste pour faire disparaître un tiret dans la colonne disque : un tiret signifie « inconnu », pas « zéro » ;
• Ne pas désactiver le gel des sauvegardes pour contourner le problème ;
• Planifier les changements de supervision hors des fenêtres de sauvegarde.

Pour une VM critique, deux stratégies tiennent la route. La première : installer pulse-agent dans la VM, ce qui fournit mémoire et systèmes de fichiers sans solliciter le QEMU Guest Agent. La seconde, plus radicale : attribuer au token un rôle personnalisé sans VM.GuestAgent.Audit, pour que l'API Proxmox refuse toute requête d'agent invité venant de Pulse. Les noms commençant par « PVE » étant réservés aux rôles intégrés, le rôle reprend les autres privilèges d'audit de PVEAuditor sur Proxmox VE 9. Comme les rôles posés sur un même chemin pour un même utilisateur se cumulent, retirez d'abord PVEAuditor si vous l'aviez accordé :

pveum role add PulseAudit --privs "VM.Audit Sys.Audit Datastore.Audit SDN.Audit Pool.Audit Mapping.Audit"
pveum acl delete / -user pulse-monitor@pve -role PVEAuditor
pveum acl delete / -token 'pulse-monitor@pve!pulse-readonly' -role PVEAuditor
pveum acl modify / -user pulse-monitor@pve -role PulseAudit
pveum acl modify / -token 'pulse-monitor@pve!pulse-readonly' -role PulseAudit
pveum user token permissions pulse-monitor@pve pulse-readonly

Vous perdez l'usage disque interne des VM sans agent, mais vous conservez tout le reste : nœuds, stockage, sauvegardes, conteneurs LXC (dont la collecte ne passe pas par le QEMU Guest Agent). Dernier recours documenté pour une fenêtre de sauvegarde sensible : arrêter Pulse (systemctl stop pulse.service dans le conteneur, ou docker stop pulse). Supervision et alertes sont alors suspendues, et l'arrêt n'annule pas une requête déjà émise.

Pulse face à Grafana, Uptime Kuma et un script bash

Pulse ne remplace pas une pile de métriques complète ni un outil de disponibilité pure. Le tableau situe les approches que nous avons déjà documentées : Grafana et Prometheus, Uptime Kuma et le script bash d'alertes.

En pratique, Pulse couvre seul le besoin d'un administrateur de serveur dédié Proxmox : vue d'ensemble, sauvegardes et alertes. Grafana reste l'outil quand il faut corréler des métriques applicatives (tick rate d'un serveur de jeu, latence d'une base de données) sur plusieurs semaines, et Uptime Kuma garde l'avantage pour une page de statut publique.

Sécuriser Pulse en production

• Ne pas exposer le port 7655 en clair sur Internet. Placez l'interface derrière un reverse proxy Nginx en HTTPS ou un VPN, et restreignez l'accès au niveau du pare-feu de l'hôte Proxmox. Pulse conserve ses identifiants de plateformes chiffrés en AES-256-GCM, mais une interface d'administration reste une cible.
• Sauvegarder le répertoire de données avec sa clé. /etc/pulse (LXC, systemd) ou le volume /data (Docker) contient la configuration, les webhooks chiffrés, les sessions, les tokens et la clé de chiffrement. Sans la clé, la configuration chiffrée ne se récupère pas. Traitez cette sauvegarde comme un secret, au même titre que vos sauvegardes chiffrées hors site.
• Un token par plateforme. Un token Proxmox VE, un token PBS, un token d'agent par hôte. Faites tourner un token avant de révoquer celui qu'une connexion active utilise, et ne désactivez jamais la séparation des privilèges pour « faire marcher » une lecture manquante.
• Épingler et vérifier les versions. Version exacte plutôt que latest, signature de l'installeur vérifiée, et sauvegarde des données avant chaque mise à jour : une mise à jour interrompt brièvement supervision et alertes, et remplacer le binaire ne revient pas sur une migration de données.
• Exécution de commandes désactivée sur les agents. Un token de supervision ne porte que les scopes agent:report et agent:config:read ; le scope agent:exec n'a rien à faire sur un hôte dont vous ne voulez que les métriques.

Conclusion

En une heure, Pulse donne à un serveur dédié Proxmox VE ce qui manque le plus souvent aux installations auto-hébergées : une supervision des sauvegardes, des disques, des conteneurs et des nœuds, avec des alertes qui arrivent sur Discord ou Telegram avant que les utilisateurs ne se plaignent. Le token Proxmox en lecture seule, l'agent sans droit d'exécution et la vigilance sur le QEMU Guest Agent pendant les fenêtres de sauvegarde sont les trois réglages qui séparent un tableau de bord utile d'un risque supplémentaire sur l'hyperviseur. Pour dimensionner l'hôte qui accueillera ce conteneur LXC parmi vos VM, notre guide dimensionner Proxmox VE sur un serveur dédié détaille la répartition CPU, RAM et stockage ; les serveurs dédiés ElypseCloud, bi-processeur Intel Xeon E5-2620 v4 ou Xeon Gold 6230 et hébergés en France, offrent de 32 à 256 Go de RAM, la ressource qu'un hyperviseur Proxmox VE consomme en premier.