Agenten auf einer Flotte

Die Seite zum Host-Agenten behandelt eine Maschine. Diese behandelt viele, und dort ändern sich die Fragen: nicht wie man ihn installiert, sondern wie man ihn wiederholbar ausrollt, wie ein sinnvoller Satz Monitore je Host aussieht, und wie das Bild sauber bleibt, wenn Hardware kommt und geht.

Nichts davon hängt an einer Art von Arbeitslast. Ein Schrank voller Datenbankserver, eine Reihe Build-Maschinen und verteilte Edge-Knoten stellen dieselben drei Aufgaben: den Agenten daraufbekommen, entscheiden was einen Incident wert ist, und nach einer verschwundenen Maschine aufräumen.

Ausrollen

Zwei Eigenschaften machen das skriptfähig.

Ein wiederverwendbares Enrollment-Token. Das Standard-Token ist einmalig verwendbar, was für eine Maschine richtig und für zwanzig falsch ist. Stellen Sie es beim Erzeugen auf wiederverwendbar und geben Sie ihm eine kurze Laufzeit. Ein Token, das eine Stunde lebt und das Rollout-Fenster abdeckt, schadet im Fall eines Lecks weniger als eines, das einen Monat lebt, und zurücknehmen lassen sich Token vor Ablauf nicht.

Ein wiederholbarer Installer. Der Installationsbefehl darf beliebig oft laufen. Auf einem bereits angemeldeten Host schaltet er in den Upgrade-Modus: er erneuert Binärdatei und Dienst, behält die bestehende Identität und braucht gar kein Token. Genau das macht ihn für Konfigurationsmanagement brauchbar, wo dieselbe Zeile bei jedem Lauf auf jedem Host ausgeführt wird.

Die einfachste Form, sobald Sie den Befehl aus der App haben:

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

Die Übergabe über die Umgebung hält das Token aus gewöhnlichen Prozessargumenten und der Prozessliste; ein wörtlicher Befehl kann trotzdem in Shell- oder Automationslogs landen. Injizieren Sie ihn aus Ihrem Secret Store und nutzen Sie die History-/Log-Regeln des Werkzeugs.

Der Installer prüft immer SHA-256 und verifiziert Ed25519, wenn ein Ed25519-fähiges OpenSSL 3 verfügbar ist. Andernfalls warnt er und fällt auf TLS plus SHA-256 zurück. Da Installer und Schlüssel vom selben Ursprung kommen, vertraut die Erstinstallation weiterhin diesem Ursprung; die spätere Selbstaktualisierung ist mit kompiliertem Schlüssel fail-closed.

Was pro Host zu überwachen ist

Ein Monitor beobachtet einen Messwert, das ist also eine bewusste Wahl und kein Automatismus. Ein Satz, der für die meisten Flotten passt:

Monitor	Je Host	Warum
availability	immer	Der einzige Agent-Monitor, der anschlägt, wenn ein Host verstummt. Ohne ihn ist eine tote Maschine unsichtbar.
disk	fast immer	Deckt alle Mountpunkte auf einmal ab, weil der Schwellwert für das vollste Dateisystem gilt.
service	einer je kritischem Prozess	Die Prüfung, die den Fall fängt, dass die Maschine läuft, aber das, wofür sie da ist, nicht.
cpu, mem	selten als Ausfall	Auf kleinen Maschinen ist eine Prozentschwelle entweder laut oder bedeutungslos, und echter Speicherdruck zeigt sich meist als toter Prozess, den der Dienst-Monitor schon fängt.

Wenn Sie CPU und Speicher zur Einordnung wollen statt zur Alarmierung, setzen Sie "breach_severity": "degraded". Das erzeugt einen Hinweis in der App, keinen Incident und keinen Push.

Geben Sie jedem Agenten einen Verfügbarkeits-Monitor. Er ist der, der die Flotte trägt. Wenn ein Host aufhört zu melden, werden die übrigen Monitore gar nicht mehr ausgewertet, sie öffnen und schließen also nichts und behalten ihre zuletzt angezeigte Bewertung. Deshalb erzeugt ein toter Host einen Incident statt einen je Messwert, und deshalb ist der Verfügbarkeits-Monitor der, dem Sie bei Stille glauben sollten.

Wie viele Monitore das sind

Multiplizieren Sie: Monitore je Host mal Hosts. Ein Host mit Verfügbarkeit, Platte und vier beobachteten Prozessen sind sechs Monitore, zwanzig davon also hundertzwanzig.

Drei Regeln entscheiden, ob das passt:

• Die Zahl der Agenten ist je Tarif begrenzt: 2 in Free, 10 in Pulse, 50 in Sentinel, 200 in Command und unbegrenzt in Enterprise. Außerhalb von Enterprise kann ein Agent höchstens 25 Monitore tragen.
• Archivierte Monitore geben ihren Platz frei, pausierte nicht. Wer am Limit steht und Monitore pausiert, um Luft zu schaffen, kommt so nicht weiter. Archivieren ist der richtige Weg.
• Die Monitor-Grenzen je Tarif stehen auf Tarife und Grenzen.

Rechnen Sie das vor dem Rollout aus und nicht danach. Auf halber Strecke ans Limit zu stoßen hinterlässt eine teilweise überwachte Flotte, und die ist schlimmer als eine unüberwachte: sie sieht aus wie Abdeckung.

Benennung

Monitornamen sind innerhalb eines Projekts eindeutig, eine Flotte braucht also ein Schema statt Improvisation. Etwas, das den Host voranstellt und den Messwert dahinter, liest sich in Listen gut und sortiert sinnvoll:

web-07 · Verfügbarkeit
web-07 · Platte
web-07 · nginx

Der Agent selbst wird über den Hostnamen erkannt, den er meldet. Wenn Sie Maschinen unter demselben Hostnamen neu aufsetzen, denken Sie daran, dass die neue Maschine sich als neuer Agent anmeldet und der alte bleibt, bis Sie ihn entfernen.

Die richtigen Prozessnamen finden

service_name trifft einen Prozessnamen, keine systemd-Unit, und auf einer Flotte wollen Sie die echten Namen und nicht die, die Sie vermuten. Zwei Wege:

Führen Sie ps -eo comm= | sort -u auf einem repräsentativen Host aus.

Oder schalten Sie für einen Agenten das Prozess-Inventar ein, das standardmäßig aus ist. Es überträgt ausschließlich Prozess- und Programmdateinamen, nie Kommandozeilen, Pfade, Benutzer oder PIDs, und das Monitor-Formular schlägt diese Namen dann vor. Für einen einzigen repräsentativen Host einzuschalten reicht meist, um die ganze Flotte einzurichten, und danach können Sie es wieder ausschalten.

Achten Sie auf Dienste, die als Skript starten. Sie erscheinen als python3, sh oder node und lassen sich nicht am Namen unterscheiden, was auf einer Flotte mehr wiegt, weil der Fehler sich dann auf jedem Host wiederholt.

Eine Maschine ersetzen

Zwei Schritte gehören in denselben Stilllegungsablauf.

1. Den Agenten entfernen, in der App. Sein Token gilt sofort nicht mehr; verbundene Monitore werden archiviert, offene Incidents gelöst und Tarifplätze freigegeben, während die Historie bleibt.
2. Die Software entfernen, auf dem Host mit uninstall.sh, was ihn auch abmeldet. Ist die Maschine schon weg, genügt Schritt 1.

Wenn mehrere Hosts gleichzeitig ausfallen

Ein zusammenhängender Ausfall, ein Schrank ohne Strom oder ein verschwundenes Netzsegment, öffnet einen Incident je betroffenem Monitor. Drei Dinge dämpfen das.

Push-Nachrichten einer Organisation werden zu einer Meldung zusammengefasst statt je Incident einzeln zugestellt, ein zusammenhängender Ausfall leert also nicht Ihren Akku.

Schlummern stellt einen Incident für Sie still, ohne ihn für das Team zu quittieren, und ist damit richtig, wenn Sie längst Bescheid wissen und daran arbeiten.

Abhängige Alarme lassen einen Monitor die Monitore benennen, von denen er abhängt. Solange ein benannter Ursprung belegt unten ist, hält der abhängige Monitor seine Alarmkette zurück, der ausgefallene Router weckt Sie also nicht einmal je Maschine dahinter. Der Incident selbst und die Statusseite bleiben davon unberührt, nur der Alarm wartet. Das wird je Monitor bewusst eingerichtet und lohnt sich für eine Flotte mit bekannter Topologie.

Was sich heute automatisieren lässt

Die REST-API ist rein lesend: Ihre API-Schlüssel lesen genau 7 Endpunkte. Programmatische Schreibzugriffe auf Monitore laufen über MCP. Die zweite Hälfte eines Rollouts, für jeden Host die richtigen Monitore anzulegen und zu verwalten, ist damit über MCP skriptfähig; REST liefert die lesende Seite.

Die Agenten selbst anzumelden nicht. Ein Enrollment-Token wird in der App erzeugt, und die Identität des Agenten entsteht beim Anmelden auf dem Host statt durch einen API-Aufruf. Praktisch heißt das: ein Handgriff je Rollout-Fenster statt einer je Maschine. Ein wiederverwendbares Token erzeugen, den Rest erledigt das Konfigurationsmanagement.

Der blinde Fleck, den Sie kennen sollten

Eine tote Maschine und eine gesunde Maschine, die uns nicht erreicht, erzeugen dasselbe Signal, weil der Zeitstempel, mit dem wir arbeiten, der des Eingangs ist. Auf einer Flotte über mehrere Standorte oder Netze hinweg ist dieser Unterschied oft das Erste, was Sie wissen wollen.

Wenn er für Sie zählt, stellen Sie jedem Verfügbarkeits-Monitor eine externe Prüfung derselben Maschine zur Seite, einen ping- oder tcp-Monitor auf eine Adresse, die sie direkt erreicht. Agent still und externe Prüfung grün heißt, wir haben einen laufenden Host aus den Augen verloren. Agent still und externe Prüfung rot heißt, der Host ist weg.