Agenten auf einer Flotte

Die Seite zum Host-Agenten behandelt eine Maschine. Auf einer Flotte ändern sich die Fragen: wie Sie den Agenten wiederholbar ausrollen, wie ein sinnvoller Satz Monitore je Host aussieht und wie das Bild sauber bleibt, wenn Hardware kommt und geht.

Das Vorgehen passt zu jeder Arbeitslast. Ein Schrank voller Datenbankserver, eine Reihe Build-Maschinen und verteilte Edge-Knoten teilen 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, hält das Risiko klein, denn ein Token gilt bis zu seinem Ablauf.

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 kürzeste 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, übergeben Sie das Token also aus Ihrem Secret Store und nutzen Sie die History- und Log-Regeln Ihres Werkzeugs. Ansible, Salt oder Puppet führen dieselbe Zeile unverändert aus, weil der Installer wiederholbar ist.

Der Installer prüft immer SHA-256 und verifiziert Ed25519, wenn ein Ed25519-fähiges OpenSSL 3 verfügbar ist. Auf anderen Systemen warnt er und prüft über TLS plus SHA-256. Installer und Schlüssel kommen vom selben Ursprung, die Erstinstallation vertraut also diesem Ursprung. Spätere Selbstaktualisierungen sind mit kompiliertem Schlüssel fail-closed.

Was pro Host zu überwachen ist

Ein Monitor beobachtet einen Messwert, also wählen Sie den Satz je Host. Ein Satz, der für die meisten Flotten passt:

Monitor	Je Host	Warum
availability	immer	Der Agent-Monitor, der anschlägt, wenn ein Host verstummt. Er macht eine tote Maschine sichtbar.
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	zur Einordnung	Auf kleinen Maschinen ist eine Prozentschwelle oft laut, und echter Speicherdruck zeigt sich meist als toter Prozess, den der Dienst-Monitor 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, ohne Incident und ohne Push.

Geben Sie jedem Agenten einen Verfügbarkeits-Monitor. Er ist der, der die Flotte trägt. Wenn ein Host aufhört zu melden, setzen die übrigen Monitore ihre Auswertung aus, 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:

• Agenten je Tarif: 2 in Free, 10 in Pulse, 50 in Sentinel, 200 in Command und unbegrenzt in Enterprise. Außerhalb von Enterprise trägt ein Agent bis zu 25 Monitore.
• Archivieren gibt den Platz frei, Pausieren behält ihn. Um am Limit Luft zu schaffen, archivieren Sie Monitore.
• Pakete erweitern beide Kontingente ohne Tarifwechsel. Die Grenzen je Tarif und die Pakete stehen unter Tarife und Limits.

Rechnen Sie das vor dem Rollout aus, dann bekommt jeder Host von Anfang an seinen vollständigen Satz.

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 teilen sich einen Namen, was auf einer Flotte mehr wiegt, weil sich eine Namenswahl dort 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 geschlossen und Tarifplätze freigegeben, während die Historie den geltenden Aufbewahrungsregeln folgt.
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, ein verschwundenes Netzsegment) öffnet einen Incident je betroffenem Monitor. Drei Funktionen halten das beherrschbar.

Push-Nachrichten einer Organisation werden zu einer Meldung zusammengefasst, statt je Incident einzeln zugestellt zu werden, Ihr Akku bleibt bei einem zusammenhängenden Ausfall also geschont.

Stummschalten 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 einmal statt einmal je Maschine dahinter. Der Incident selbst und die Statusseite laufen wie gewohnt weiter, nur der Alarm wartet. Richten Sie das je Monitor ein, es lohnt sich für eine Flotte mit bekannter Topologie.

Das Rollout automatisieren

Die REST-API legt Monitore mit einem API-Schlüssel an, ändert und löscht sie, und sie listet und entfernt Agenten. Über MCP legt ein KI-Agent dieselben Monitore an und verwaltet sie. Die zweite Hälfte eines Rollouts, für jeden Host die richtigen Monitore anzulegen, läuft damit aus Ihren Skripten oder über Ihren Agenten.

Die Anmeldung beginnt in der App: Dort erzeugen Sie das Token, und jeder Host legt seine Identität beim Anmelden selbst an. Ein Flotten-Rollout braucht damit einen Handgriff je Rollout-Fenster statt einen je Maschine. Erzeugen Sie ein wiederverwendbares Token, den Rest erledigt das Konfigurationsmanagement.

Toten Host und verlorene Verbindung unterscheiden

Auf einer Flotte über mehrere Standorte oder Netze hinweg ist die erste Frage bei einem Ausfall oft, ob ein Host ausgefallen ist oder nur seine Verbindung verloren hat. Aus Sicht des Agenten sieht beides gleich aus, weil Perstat mit dem Eingangszeitpunkt jeder Meldung arbeitet.

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: Der Host läuft, und seine Verbindung zu Perstat ist unterbrochen. Agent still und externe Prüfung rot: Der Host ist weg.

Nächste Schritte

• Host-Agent: was der Agent misst, im Einzelnen.
• API: API-Schlüssel für Monitore und Agenten.