Private Agents

Überblick

Ein Private Agent läuft in Ihrer eigenen Infrastruktur und überwacht Dienste, die OKStatus aus dem öffentlichen Internet nicht erreicht — interne APIs, Datenbanken, Intranet-Anwendungen. Er holt seine Prüfungen über ausschließlich ausgehendes HTTPS von OKStatus: nichts freizugeben, kein eingehender Port, kein VPN. Verfügbar ab dem Tarif Max (Max: 5 Agents, Enterprise: 20).

Ausrollen

Die Seite „Private Agents“ mit zwei registrierten Agents

Installieren Sie das Helm-Chart. Es gibt zwei Wege, dem Agent seine Identität zu geben — wählen Sie einen.

Empfohlen: zustandslose Zugangsdaten

Registrieren Sie einmalig, um das langlebige Zugangsdatenpaar zu erhalten, und betreiben Sie den Agent dann aus einem Secret — kein Token zu verbrauchen, kein Volume zu erhalten, unempfindlich gegen Neustarts und Umplanungen:

helm install okstatus-agent okstatus/private-agent \
  --set credentials.agentId=<agentId> \
  --set credentials.agentSecret=<agentSecret>

Das Paar erhalten Sie auf der Seite „Private Agents”: Menü des Agents (⋮) → Zustandslose Zugangsdaten, oder Reiter Kubernetes (env) im Ausroll-Dialog und dort Zugangsdaten erzeugen. Das Geheimnis wird einmal angezeigt; ein erneutes Erzeugen ersetzt es.

Für ein einfaches Deployment (ohne Helm) heißen die entsprechenden Umgebungsvariablen OKSTATUS_AGENT_ID, OKSTATUS_AGENT_SECRET, OKSTATUS_AGENT_NAME und AGGREGATOR_URL=https://backend.okstatus.eu.

Veraltet: einmaliges Token

Der Agent tauscht das Token beim ersten Start ein und speichert das Ergebnis in einem kleinen PVC (erforderlich — ohne ihn braucht ein Neustart ein neues Token):

helm install okstatus-agent okstatus/private-agent \
  --set token=oksa_live_xxxxxxxx

Das Token stammt von der Seite „Private Agents” und ist einmalig verwendbar.

Ein Agent = eine laufende Instanz

Die Zugangsdaten eines Private Agent sind eine Identität. Betreiben Sie genau einen Pod je Zugangsdatenpaar:

Das Chart liefert bewusst replicas: 1 und strategy: Recreate — nie RollingUpdate (dessen Überhang ließe kurzzeitig zwei Pods laufen und würde Heartbeats und Prüfungen dieses Agents verdoppeln).
Der Server setzt es ebenfalls durch. Startet eine zweite Instanz mit denselben Zugangsdaten, weist die Einzelinstanz-Sperre des Backends sie mit 409 ab, und dieser Pod beendet sich mit dem Protokolleintrag „another instance of this agent is already running”. replicas hochzuskalieren oder ein zweites Deployment mit denselben Zugangsdaten auszurollen bringt also keinen höheren Durchsatz — die zusätzlichen Pods beenden sich einfach.

Bei einem sauberen Neustart gibt der scheidende Pod seine Sperre frei, ein Ersatz übernimmt also sofort; nach einem harten Abschuss übernimmt ein Ersatz binnen etwa 2–3 Minuten.

Monitor auf einem Agent anlegen und testen

Sobald Ihre Organisation mindestens einen privaten Agent hat, fragt der Dialog Neuer Monitor zuerst, von wo die Checks laufen:

OKStatus-Netzwerk — die öffentlichen Regionen, für alles, was aus dem Internet erreichbar ist;
Meine privaten Agents — wählen Sie direkt einen oder mehrere Ihrer Agents. Interne Adressen (10.0.0.5, redis.internal, *.svc.cluster.local…) sind erlaubt.

Im Agent-Modus heißt die Schaltfläche Vom Agent testen: Der Test läuft auf dem ersten gewählten Agent, aus Ihrem Netzwerk, und seine echte Antwort erscheint im Dialog (zum Beispiel REDIS · bureau-lyon). Es ist eine einmalige Probe — nichts wird gespeichert, kein Alarm gesendet, der Status des Monitors ändert sich nicht. Die Test-Schaltfläche im Bearbeitungsbereich verhält sich bei einem Monitor mit ausschließlich privaten Regionen genauso.

Meldung	Was tun
Kein privater Agent ist online	Der Agent hat seit 5 Minuten keinen Heartbeat gesendet: Pod oder Dienst prüfen.
Agent … ist zu alt für Tests	Agent-Image aktualisieren. Das Monitoring läuft weiter; nur die Test-Schaltfläche braucht es.
Agent … hat nicht innerhalb von 25 s geantwortet	Der Agent ist online, aber ausgelastet oder von `backend.okstatus.eu` getrennt: Logs prüfen.

Belastbarkeit

Der zustandslose Modus (Zugangsdaten) braucht kein persistentes Volume — der Pod lädt seine Identität bei jedem Start aus dem Secret und registriert sich nie neu.
Der Token-Modus braucht persistence.enabled (einen PVC), damit das bei der Registrierung erhaltene Zugangsdatum Neustarts übersteht; ohne ihn verlangt ein Neustart ein rotiertes Token.

Fehlersuche

Symptom	Ursache / Abhilfe
`enrollment token rejected — already used or revoked`	Das einmalige Token war schon verbraucht (oder Sie sind im Token-Modus ohne PVC, sodass bei jedem Start neu registriert wird). Token rotieren und aktualisieren, oder auf zustandslose Zugangsdaten wechseln.
CrashLoopBackOff direkt nach dem Ausrollen	Fast immer das Token oben, oder die Schlüssel im Zugangsdaten-Secret sind falsch benannt (sie müssen `agentId` / `agentSecret` heißen).
`409` / „another instance is already running”	Zwei Pods teilen sich ein Zugangsdatenpaar. Bei `replicas: 1` bleiben; für mehr Kapazität einen eigenen Agent ausrollen.
Der Agent erscheint nie im Dashboard	Ausgehendes HTTPS zu `backend.okstatus.eu` prüfen und `kubectl logs` am Pod ansehen.
`401 INVALID_AGENT_ID`, oder der Agent beendet sich beim Start mit einer Klage über die ID	In `OKSTATUS_AGENT_ID` steht der Name des Agents — dort gehört seine UUID hin (Agent-Menü → Zustandslose Zugangsdaten).
`401 UNAUTHORIZED` im zustandslosen Modus, oder der Agent klagt über das Geheimnis	In `OKSTATUS_AGENT_SECRET` steht das Registrierungstoken `oksa_live_…` — dort gehört das Geheimnis `oksas_…` hin. Erzeugen Sie eines über das Agent-Menü.