Agents sur une flotte

La page agent hôte traite d’une machine. Celle-ci traite d’un grand nombre, et les questions y changent : non pas comment l’installer, mais comment le déployer 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.

Rien ici ne dépend d’un type de charge. 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 posent les mêmes trois problèmes : 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 fuite moins gravement qu’un jeton qui vit un mois, et les jetons ne peuvent pas être retirés avant leur 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 simple, 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-la depuis votre coffre de secrets et appliquez la politique de logs.

L’installeur contrôle toujours SHA-256 et vérifie Ed25519 si un OpenSSL 3 compatible est disponible. Sinon, il avertit et se rabat sur TLS plus SHA-256. Installeur et clé venant de la même origine, la première installation lui fait toujours confiance ; la mise à jour ultérieure est fail-closed avec une clé compilée.

Quoi surveiller par hôte

Un monitor surveille un indicateur, c’est donc un choix délibéré et non un réglage par défaut. Un ensemble qui convient à la plupart des flottes :

Monitor	Par hôte	Pourquoi
availability	toujours	Le seul monitor d’agent qui se déclenche quand un hôte se tait. Sans lui, une machine morte est invisible.
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	rarement en panne	Sur de petites machines, un seuil en pourcentage est soit bruyant soit dénué de sens, et une vraie pression mémoire se manifeste le plus souvent par un processus mort, que le monitor de service attrape déjà.

Si vous voulez le CPU et la mémoire pour le contexte plutôt que pour être réveillé, mettez "breach_severity": "degraded". Cela produit un avis dans l’application, aucun incident et aucune 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 ne sont plus évalués du tout : 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 :

• Le nombre d’agents est plafonné par formule : 2 en Free, 10 en Pulse, 50 en Sentinel, 200 en Command et sans limite en Enterprise. Hors Enterprise, un agent peut porter au maximum 25 monitors.
• Les monitors archivés libèrent leur place, les monitors en pause non. Si vous êtes à la limite et mettez des monitors en pause pour faire de la place, cela ne fonctionnera pas. Il faut archiver.
• Les limites de monitors par formule sont sur formules et limites.

Faites ce calcul avant le déploiement et non après. Atteindre la limite à mi-parcours laisse une flotte à moitié surveillée, ce qui est pire qu’une flotte non surveillée : cela ressemble à de la couverture.

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 ne peuvent pas être distingués par leur nom, ce qui pèse davantage sur une flotte, parce que l’erreur se répète alors 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, sans supprimer l’historique.
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 ou un segment réseau qui disparaît, ouvre un incident par monitor touché. Trois choses atténuent cela.

Les notifications push d’une organisation sont regroupées en un seul message au lieu d’un par incident, une panne corrélée ne vide donc pas la batterie de votre téléphone.

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, le routeur disparu ne vous réveille donc pas une fois par machine située derrière. L’incident lui-même et la page de statut n’en sont pas affectés, seule l’alerte attend. Cela se configure délibérément par monitor et vaut la peine sur une flotte à topologie connue.

Ce que vous pouvez automatiser aujourd’hui

L’API REST est strictement en lecture : ses clés lisent exactement 7 endpoints. Les écritures programmatiques sur les monitors passent par MCP. La seconde moitié d’un déploiement, créer et gérer les bons monitors pour chaque hôte, se scripte donc via MCP ; REST fournit la partie lecture.

Enrôler les agents eux-mêmes, non. Un jeton d’enrôlement se crée dans l’application, et l’identité de l’agent naît sur l’hôte au moment de l’enrôlement plutôt que par un appel d’API. En pratique, cela fait un geste manuel par fenêtre de déploiement au lieu d’un par machine : créez un jeton réutilisable, la gestion de configuration fait le reste.

L’angle mort qu’il faut connaître

Une machine morte et une machine en bonne santé qui n’arrive pas à nous joindre produisent le même signal, parce que l’horodatage sur lequel nous travaillons est celui de la réception. Sur une flotte répartie entre plusieurs sites ou réseaux, cette différence est souvent la première chose que vous voulez savoir.

Si elle compte pour vous, 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 signifie que nous avons perdu de vue un hôte qui fonctionne. Agent silencieux et vérification externe au rouge signifie que l’hôte a disparu.