Agents sur une flotte

La page agent hôte traite d’une machine. Sur une flotte, les questions changent : comment déployer l’agent de façon reproductible, à quoi ressemble un ensemble sensé de monitors par hôte, et comment garder une image nette quand le matériel arrive et repart.

L’approche convient à toute charge de travail. Une baie de serveurs de base de données, un parc de machines de build et des nœuds répartis en périphérie partagent les mêmes trois tâches : installer l’agent, décider ce qui mérite un incident, et faire le ménage après une machine disparue.

Le déploiement

Deux propriétés rendent cela scriptable.

Un jeton d’enrôlement réutilisable. Le jeton par défaut est à usage unique, ce qui convient pour une machine et pas pour vingt. À la création, passez-le en réutilisable et donnez-lui une durée de vie courte. Un jeton qui vit une heure et couvre la fenêtre de déploiement limite l’exposition, car un jeton reste valable jusqu’à son expiration.

Un installeur relançable. La commande d’installation peut être exécutée autant de fois que voulu. Sur un hôte déjà enrôlé, elle passe en mode mise à jour : elle rafraîchit le binaire et le service, conserve l’identité existante et n’a besoin d’aucun jeton. C’est précisément ce qui la rend utilisable depuis un outil de gestion de configuration, où la même ligne est exécutée sur chaque hôte à chaque passage.

La forme la plus courte, une fois la commande récupérée dans l’application :

TOKEN=psag_…
for host in $(cat hosts.txt); do
  ssh "$host" "PERSTAT_TOKEN=$TOKEN sh -c \"\$(curl -fsSL https://agent.perstat.io/install.sh)\""
done

Le passage par l’environnement garde le jeton hors des arguments ordinaires et de la liste des processus. Une commande littérale peut néanmoins entrer dans les journaux du shell ou de l’automatisation : injectez donc le jeton depuis votre coffre de secrets et appliquez la politique d’historique et de logs de votre outil. Ansible, Salt ou Puppet exécutent la même ligne telle quelle, puisque l’installeur est relançable.

L’installeur contrôle toujours SHA-256 et vérifie Ed25519 si un OpenSSL 3 compatible est disponible. Sur les autres systèmes, il avertit et vérifie via TLS plus SHA-256. L’installeur et la clé venant de la même origine, la première installation fait confiance à cette origine. Les mises à jour ultérieures sont fail-closed avec une clé compilée.

Quoi surveiller par hôte

Un monitor surveille un indicateur, c’est donc vous qui choisissez l’ensemble par hôte. Un ensemble qui convient à la plupart des flottes :

Monitor	Par hôte	Pourquoi
availability	toujours	Le monitor d’agent qui se déclenche quand un hôte se tait. Il rend visible une machine morte.
disk	presque toujours	Couvre tous les points de montage d’un coup, puisque le seuil s’applique au système de fichiers le plus rempli.
service	un par processus critique	La vérification qui attrape le cas où la machine tourne mais où ce pour quoi elle existe ne tourne pas.
cpu, mem	pour le contexte	Sur de petites machines, un seuil en pourcentage est souvent bruyant, et une vraie pression mémoire se manifeste le plus souvent par un processus mort, que le monitor de service attrape.

Pour le CPU et la mémoire en contexte plutôt que pour être réveillé, mettez "breach_severity": "degraded". Cela produit un avis dans l’application, sans incident ni notification push.

Donnez à chaque agent un monitor de disponibilité. C’est lui qui porte la flotte. Quand un hôte cesse de remonter ses mesures, les autres monitors suspendent leur évaluation : ils n’ouvrent ni ne ferment rien et conservent leur dernière valeur affichée. C’est pourquoi un hôte mort produit un incident et non un par indicateur, et c’est aussi pourquoi le monitor de disponibilité est celui auquel se fier quand un hôte se tait.

Combien de monitors cela fait

Multipliez : monitors par hôte fois hôtes. Un hôte avec disponibilité, disque et quatre processus surveillés fait six monitors, donc cent vingt pour vingt hôtes.

Trois règles décident si cela tient :

• Agents par formule : 2 en Free, 10 en Pulse, 50 en Sentinel, 200 en Command et sans limite en Enterprise. Hors Enterprise, un agent porte jusqu’à 25 monitors.
• Archiver libère la place, mettre en pause la garde. Pour faire de la place à la limite, archivez des monitors.
• Les modules étendent les deux quotas sans changer de formule. Les limites par formule et les modules sont sur formules et limites.

Faites ce calcul avant le déploiement, et chaque hôte reçoit son ensemble complet dès le départ.

Le nommage

Les noms de monitors sont uniques au sein d’un projet, une flotte a donc besoin d’un schéma plutôt que d’improvisation. Quelque chose qui place l’hôte devant et l’indicateur derrière se lit bien dans les listes et se trie correctement :

web-07 · disponibilité
web-07 · disque
web-07 · nginx

L’agent lui-même est identifié par le nom d’hôte qu’il remonte. Si vous reconstruisez des machines sous le même nom d’hôte, gardez en tête que la machine reconstruite s’enrôle comme un nouvel agent et que l’ancien reste tant que vous ne le retirez pas.

Trouver les bons noms de processus

service_name correspond à un nom de processus et non à une unité systemd, et sur une flotte vous voulez les vrais noms, pas ceux que vous supposez. Deux moyens :

Lancez ps -eo comm= | sort -u sur un hôte représentatif.

Ou activez l’inventaire des processus pour un agent, désactivé par défaut. Il ne transmet que des noms de processus et d’exécutables, jamais de lignes de commande, de chemins, d’utilisateurs ni de PID, et le formulaire du monitor propose ensuite ces noms. L’activer sur un seul hôte représentatif suffit généralement à configurer toute la flotte, et vous pouvez le désactiver ensuite.

Faites attention aux services qui démarrent sous forme de script. Ils apparaissent comme python3, sh ou node et partagent un nom, ce qui pèse davantage sur une flotte, où un choix de nommage se répète sur chaque hôte.

Remplacer une machine

Deux étapes appartiennent à la même routine de retrait.

1. Retirer l’agent dans l’application. Son jeton cesse immédiatement de fonctionner. Les monitors liés sont archivés, leurs incidents ouverts résolus et leurs places libérées, tandis que l’historique suit les règles de rétention applicables.
2. Retirer le logiciel sur l’hôte avec uninstall.sh, ce qui le désinscrit également. Si la machine a déjà disparu, l’étape 1 suffit.

Quand plusieurs hôtes tombent en même temps

Une panne corrélée (une baie qui perd son alimentation, un segment réseau qui disparaît) ouvre un incident par monitor touché. Trois fonctionnalités gardent cela maîtrisable.

Les notifications push d’une organisation sont regroupées en un seul message au lieu d’un par incident, et la batterie de votre téléphone est ménagée lors d’une panne corrélée.

La mise en veille rend un incident silencieux pour vous sans l’acquitter pour l’équipe, ce qui est le bon geste quand vous êtes déjà au courant et en train d’agir.

Les alarmes dépendantes permettent à un monitor de nommer les monitors dont il dépend. Tant qu’une origine nommée est prouvée en panne, le monitor dépendant retient sa chaîne d’alerte, et le routeur disparu vous réveille une fois au lieu d’une fois par machine située derrière. L’incident lui-même et la page de statut continuent normalement, seule l’alerte attend. Configurez-le par monitor : cela vaut la peine sur une flotte à topologie connue.

Automatiser le déploiement

L’API REST crée, modifie et supprime des monitors avec une clé API, et elle liste et retire des agents. Via MCP, un agent IA crée et gère les mêmes monitors. La seconde moitié d’un déploiement, créer les bons monitors pour chaque hôte, se pilote donc depuis vos scripts ou depuis votre agent.

L’enrôlement commence dans l’application : vous y créez le jeton, et chaque hôte crée sa propre identité en s’enrôlant. Un déploiement de flotte demande ainsi un geste manuel par fenêtre de déploiement au lieu d’un par machine. Créez un jeton réutilisable, et la gestion de configuration fait le reste.

Distinguer un hôte mort d’une connexion perdue

Sur une flotte répartie entre plusieurs sites ou réseaux, la première question pendant une panne est souvent de savoir si un hôte est mort ou s’il a perdu sa connexion. Du point de vue de l’agent, les deux se ressemblent, parce que Perstat travaille avec l’heure d’arrivée de chaque remontée.

Associez à chaque monitor de disponibilité une vérification externe de la même machine, un monitor ping ou tcp sur une adresse qui l’atteint directement. Agent silencieux et vérification externe au vert : l’hôte fonctionne, et sa connexion à Perstat est interrompue. Agent silencieux et vérification externe au rouge : l’hôte a disparu.

Pour aller plus loin

• Agent hôte : ce que l’agent mesure, en détail.
• API : des clés API pour les monitors et les agents.