Host-Agent-Check

Was er prüft

Ein Host-Agent-Monitor bindet sich an einen Agenten, der auf einem Ihrer Hosts installiert ist, und beobachtet eine Metrik. availability beobachtet, ob sich der Agent noch meldet. cpu, mem und disk vergleichen die Auslastung in Prozent mit einem Schwellenwert, und service prüft, ob ein benannter Prozess läuft. Der Agent meldet an die Control Plane, und der Server bewertet den jüngsten Bericht etwa alle 30 s. Ein Verstoß öffnet einen Incident, mit Push gemäß notify_push, oder löst nur einen In-App-Hinweis aus, wie breach_severity es festlegt. Ein Agent trägt mehrere Monitore, einen je Metrik oder Prozess.

Wann Sie ihn einsetzen

• Ein Host betreibt etwas ohne prüfbaren Port, oder der Port antwortet noch, während dem Host Speicher oder Plattenplatz ausgehen.
• Ein Prozess muss laufen: eine Datenbank, ein Queue-Worker oder ein Reverse Proxy. Ein Neustart, der kürzer ist als die Toleranz, zählt nicht als Verstoß.
• Ein Host soll Alarm auslösen, wenn er gar nicht mehr meldet, mit einer Toleranz, damit ein Reboot innerhalb der Toleranz keinen Incident öffnet.

Der Check misst nichts über das Netz. Für die Erreichbarkeit eines Ports oder einer URL aus dem Internet brauchen Sie den Ping-, TCP- oder HTTP(S)-Check. Ein Cronjob oder Batch-Lauf ohne beobachtbaren Prozess braucht den Heartbeat-Check.

Seitlich wischen, um die Produktansicht anzusehen.

app.perstat.io

Konfiguration

Agent. Kein Netzziel. Der Monitor bindet sich über die agent_id an einen Host-Agenten Ihrer Organisation, und das Formular listet die registrierten Agenten. Der Bericht kommt vom Host, deshalb nimmt der Check weder Regionen noch IP-Familien noch ein eigenes Intervall.

So läuft ein Check ab

1. Der Agent auf dem Host meldet an die Control Plane. Etwa alle 30 s lädt der Server den jüngsten Bericht des Agenten für diesen Monitor. Keine Prüfregion ist beteiligt, und der Check berührt den Host nie über das Netz.
2. availability: Der Server vergleicht das Alter des letzten Berichts mit grace_seconds. Ein Bericht, der älter ist als die Toleranz, ist ein Verstoß.
3. cpu, mem, disk: nur bewertet, solange der letzte Bericht höchstens 180 s alt ist, und ein Wert über threshold ist ein Verstoß. Ohne frischen Wert zeichnet der Durchlauf kein Ergebnis auf, statt einen Fehlalarm auszulösen. Den stummen Host erkennt die Metrik availability.
4. service: nur bewertet mit frischem Bericht und frischem Eintrag für den benannten Prozess. Ein Prozess, der länger als grace_seconds nicht läuft, ist ein Verstoß.
5. Je nach breach_severity wird ein Verstoß als fehlgeschlagen mit Schwere critical oder als eingeschränkt gewertet. Critical öffnet einen Incident mit Push gemäß notify_push, degraded löst nur einen In-App-Hinweis aus. Alarm und Erholung liegen fest bei je 1 Bewertung, deshalb entscheidet der nächste Durchlauf.

Was ein Ergebnis enthält

Zustand und Schwere

Bestanden, eingeschränkt oder fehlgeschlagen, mit Schwere ok, degraded oder critical. Die Region ist agent, das Kennzeichen eines serverseitigen Checks.

Detailzeile

Eine Zeile mit dem bewerteten Fakt. Sie zeigt das Alter des letzten Berichts gegen die Toleranz, den Wert gegen den Schwellenwert (CPU 95% > 90%) oder den Prozess mit Prozesszahl und CPU-Anteil.

Latenz und Antwortcode

Über das Netz wird nichts gemessen, deshalb trägt ein Ergebnis weder Antwortzeit noch Statuscode.

Zustände und Schwere

• okDer letzte Bericht liegt innerhalb der Toleranz, der Wert liegt auf oder unter dem Schwellenwert, oder der Prozess läuft.
• eingeschränktEin Verstoß mit breach_severity auf degraded. Er wird aufgezeichnet und als In-App-Hinweis gezeigt, ohne Incident und ohne Push.
• ausgefallenEin Verstoß mit breach_severity auf critical, der Voreinstellung. Der Agent blieb über die Toleranz hinaus stumm, ein Wert stieg über den Schwellenwert, oder der Prozess stand länger als die Toleranz still. Der Verstoß öffnet einen Incident, mit Push gemäß notify_push.
• FehlerErscheint nur in einem Testlauf. Lässt sich die Metrik nicht bewerten, zum Beispiel ohne frischen Bericht, antwortet der Lauf mit Fehler und einer Diagnose. Nichts wird gespeichert, und kein Incident öffnet sich.
• ausstehendNoch kein Ergebnis, direkt nach dem Anlegen oder solange der Agent keinen frischen Wert für die Metrik gesendet hat. Der Durchlauf zeichnet lieber nichts auf als einen Fehlalarm.

Das Signal kommt von Ihrem Host oder Ihrem Job, ohne Regionen und ohne Quorum. Deshalb zählt schon eine ausgebliebene Meldung. Alarm und Erholung liegen fest bei je 1 Bewertung. Der Durchlauf, der den Verstoß sieht, öffnet den Incident, und eine bestandene Bewertung zählt als Erholung.

Tarife und Grenzen

Host-Agenten

2 in Free, 10 in Pulse, 50 in Sentinel und 200 in Command. In Enterprise gelten individuelle Kontingente. Ein Zusatzpaket bringt 10 weitere Agenten für 19 €.

Monitore je Agent

25 in Free, Pulse, Sentinel und Command. In Enterprise gelten individuelle Kontingente. Ein Host-Agent-Monitor zählt hier, nicht gegen das Kontingent der regionalen Monitore.

Intervall und Regionen

Nicht anwendbar. Der Server bewertet etwa alle 30 s, und die Intervall-Untergrenzen und Regionszahlen der Tarife gelten für diesen Typ nicht.

Alle Tarifgrenzen vergleichen

Aus der Pipeline oder von einem Agenten

Dieselbe config gilt im Deploy-Schritt, in einem MCP-Client wie Claude Code und im Formular oben. create_monitor braucht einen API-Schlüssel für die ganze Organisation. Wenn Sie regions weglassen, wählt der Tarif seine Voreinstellung.

{
  "name": "web-01 CPU",
  "type": "agent",
  "config": {
    "agent_id": "agt_...",
    "metric": "cpu",
    "threshold": 90,
    "breach_severity": "degraded",
    "notify_push": true
  }
}

Jede Schnittstelle mit ihrer Grenze

Grenzen

• Der Agent meldet vier Metriken (Verfügbarkeit, CPU, Speicher und Platte) und den Zustand eines benannten Prozesses. Andere Metriken und eigene Werte gibt es nicht.
• CPU, Speicher und Platte werden nicht bewertet, solange der Agent schweigt. Kombinieren Sie einen Schwellenwert-Monitor mit einem availability-Monitor auf demselben Agenten, um den stummen Host zu erkennen.
• grace_seconds setzen Sie über die API oder MCP. Das Formular behält beim Bearbeiten den gespeicherten Wert.
• Der Typ hat kein eigenes Intervall, keine Regionen und keine eigene Alarmregel, und das Formular blendet alle drei aus. Der Server bewertet alle Agent-Monitore etwa alle 30 s in einem Durchlauf und ignoriert regions in einer Anfrage. interval_seconds wird beim Bearbeiten gespeichert und im Monitor gezeigt, aber die Bewertung liest weder diesen Wert noch die 60 s, die beim Anlegen gesetzt werden.
• agent_id muss einen Agenten nennen, der bereits in Ihrer Organisation registriert ist. Die ID stammt aus der Registrierung des Agenten, der Monitor erzeugt sie nicht.

Verwandte Checktypen

• Heartbeat-CheckEine geheime URL, die Ihr Job planmäßig aufruft. Schweigen über Periode plus Toleranz hinaus oder ein gemeldeter Fehlschlag setzt den Monitor auf ausgefallen.
• Ping-CheckErreichbarkeit eines Hosts über ICMP-Echo: Antworten, Verlust und mittlere Umlaufzeit aus jeder Region.
• TCP-Port-CheckOb ein Port eine Verbindung annimmt, wahlweise mit dem Zertifikat, das er ausliefert.

Alle Checktypen