Einen Endpunkt mit Zugangsdaten überwachen

Job-Reports gehören zu Vaicoa Pro und Vaicoa Team.

Ein Uptime-Check kann keinen Endpunkt überwachen, der ein Token braucht oder an einer privaten Adresse liegt. Führ die Anfrage selbst per Cron aus, auf einer Maschine, die den Endpunkt erreicht, und melde das Ergebnis als Job. Vaicoa alarmiert dich dann, wenn die Anfrage fehlschlägt oder nicht mehr erfolgreich ist, und die Zugangsdaten verlassen nie deine Maschine.

Checks senden keine Zugangsdaten, Header oder Query-Strings und verbinden sich nur mit öffentlichen Adressen. So landet nichts Geheimes in geteilten Berichten oder in Claudes Antworten, und kein Check lässt sich in ein privates Netz richten. Siehe Uptime-Checks in der Referenz.

Was du brauchst: einen Server, auf dem der Agent läuft und der den Endpunkt erreicht. Die Beispiele nutzen https://10.0.1.5:8443/health und ein Bearer-Token.

Schritte

1. Leg die Zugangsdaten in einer Datei ab, die nur root lesen kann, zum Beispiel /etc/cloudviewer-probe/api-health.header mit Modus 0600:

   Authorization: Bearer <your-api-token>

   curl liest Header mit -H @file aus einer Datei (curl 7.55 oder neuer). So steht das Geheimnis nicht auf der Kommandozeile, wo andere Benutzer es in der Prozessliste sehen könnten.

2. Schreib ein kleines Prüfskript, /usr/local/bin/api-health, und mach es ausführbar (chmod 755):

   #!/bin/sh
   # Endet mit Exit-Code ungleich 0, wenn der Endpunkt fehlschlägt, und loggt den Grund.
   out=$(curl -fsS --max-time 10 -o /dev/null \
     -H @/etc/cloudviewer-probe/api-health.header \
     https://10.0.1.5:8443/health 2>&1) || {
     rc=$?
     logger -p user.warning -t api-health "$out"
     exit "$rc"
   }

   -f lässt curl bei einem HTTP-Status ab 400 fehlschlagen, --max-time bei einem Hänger. Ein Job-Report trägt keine Nachricht. Das Skript schreibt den Fehler von curl deshalb mit Priorität Warning nach journald, wo er im Log-Kontext des Servers erscheint. Für ein Zertifikat deiner eigenen CA ergänz --cacert.

3. Führ es einmal von Hand aus, als root, und prüf, dass es erfolgreich ist:

   /usr/local/bin/api-health; echo "exit $?"

   Ein Job, der nie erfolgreich war, gilt nie als veraltet. Der erste Report sollte deshalb ein Erfolg sein.

4. Füg die Cron-Zeile in die Crontab von root ein:

   */5 * * * * cloudviewer-report --job api-health --max-age 20m -- /usr/local/bin/api-health

   cloudviewer-report führt das Skript aus, sendet Exit-Code und Dauer und gibt den Exit-Code unverändert zurück. Das Agent-Token liest es aus /etc/cloudviewer-agent/agent.env, das nur root lesen kann. Um den Job als anderer Benutzer auszuführen, gib diesem Benutzer eine Kopie des Tokens und übergib --token-file /path/to/token.

Was du siehst

Nach dem ersten Durchlauf erscheint api-health im Abschnitt Jobs der Detailansicht des Servers, mit letztem Durchlauf und letztem Erfolg. Zwei Alarme kommen mit:

• Job failed, wenn der letzte Durchlauf fehlgeschlagen ist und fünf Minuten lang kein erfolgreicher Durchlauf ihn abgelöst hat.
• Job stale, wenn länger als --max-age kein Durchlauf erfolgreich war, zum Beispiel weil Cron ihn nicht mehr ausführt. Setz --max-age ein paar Intervalle länger als den Zeitplan, damit ein einzelner ausgefallener Durchlauf keinen Alarm auslöst.

Bei einem fehlgeschlagenen Job öffnet Warum er fehlgeschlagen ist den Log-Kontext. Dort zeigt die Zeile von logger den Fehler von curl, etwa eine Zeitüberschreitung oder den HTTP-Status.

Der Endpunkt liegt auf einer anderen Maschine

Der Job muss nicht auf dem Server laufen, den er überwacht. Gehört der Endpunkt zu einem anderen überwachten Server, melde mit dem Agent-Token dieses Servers (--token-file), und der Job erscheint stattdessen in dessen Ansicht. Auf einer Maschine ohne Agent nutz statt cloudviewer-report den curl-Aufruf aus Bei fehlgeschlagenen Jobs Bescheid bekommen. Die logger-Zeile bleibt dann auf dieser Maschine.

Grenzen

Ein Token kann 2 Reports pro Minute senden, mit einem Burst von 16. Ein Durchlauf alle fünf Minuten liegt also weit darunter. Ein Server kann 16 Jobs haben. Job-Namen bestehen aus Kleinbuchstaben, Ziffern, -, _ und ., bis zu 64 Zeichen. Alle Felder und Fehlercodes: Job-Reports-API.

Weiter: Wenn etwas Aufmerksamkeit braucht verfolgt einen fehlgeschlagenen Job vom Alarm bis zur Ursache.