Das Problem: drei Tage gerechnet, nichts abgegeben

In meinem Lernnetz rechnen mehrere Rechner für BOINC-Projekte wie LHC@home und Milkyway@home. Eines Morgens fiel mir auf, dass ein Rechner seit drei Tagen an derselben Aufgabe saß. Ein Blick in die Meldungen zeigte: Der Job war längst fertig – sogar 65-mal. Weil BOINC ihn immer wieder anhielt und der Container das Anhalten nicht vertrug, startete er jedes Mal von vorn und wurde nie abgegeben.

Die Ursache war schnell behoben. Unangenehm war etwas anderes: Niemand hatte es bemerkt. Der Rechner lief, die CPU war ausgelastet, alles sah normal aus. Genau für so etwas gibt es Überwachung – also sollte Checkmk künftig Alarm schlagen, wenn BOINC zu viele Fehler meldet oder zu lange kein Ergebnis mehr liefert.

Schema: BOINC-Client und Job-Log liefern Daten an einen Local Check, der Checkmk-Agent gibt vier Dienste an Checkmk weiter
Bild 1 - Aufbau: Ein kleines Skript liest BOINC aus, Checkmk zeigt vier Dienste

Die Idee: ein Local Check

Checkmk kann eigene Prüfungen ausführen, ohne dass man ein Plugin programmieren muss. Ein sogenannter Local Check ist ein beliebiges Skript im Ordner local des Agenten. Es gibt pro Zeile einen Dienst aus: Status, Name, Messwerte und einen Text. Den Rest erledigt Checkmk. 


0 "BOINC Client" - Client läuft und rechnet
2 "BOINC Fehler 24h" fehler=20;1;3 20 Fehlermeldungen in 24 h, zuletzt: ...
0 "BOINC Ergebnisse" stunden_seit_ergebnis=0.6;18;36|ergebnisse_24h=2 letztes Ergebnis vor 0.6 h
0 "BOINC Aufgaben" laufend=1|gesamt=1 1 laufen, 1 insgesamt

Die erste Zahl ist der Status: 0 = OK, 1 = Warnung, 2 = kritisch. Hinter den Messwerten stehen die Schwellen für Warnung und kritisch. Checkmk zeichnet die Werte zusätzlich als Graphen auf.

Was das Skript prüft

DienstWoherWarnungKritisch
BOINC Clientläuft der Dienst, ist das Rechnen angehalten?angehaltenDienst aus
BOINC Fehler 24hMeldungen von boinccmd --get_messagesab 1ab 3
BOINC ErgebnisseZeitstempel im Job-Logälter als 18 hälter als 36 h
BOINC Aufgabenboinccmd --get_taskskeine läuft–

Als Fehler zählen Meldungen wie computation error, aborted und genau die Zeile, die mir die drei Tage eingebrockt hat: exited with zero status but no 'finished' file. Das Job-Log (job_log_<projekt>.txt im BOINC-Datenordner) enthält pro fertigem Ergebnis eine Zeile, die mit einem Unix-Zeitstempel beginnt. Daraus ergibt sich, wie lange das letzte Ergebnis zurückliegt.

Das Skript für Linux

Der Kern in Python: Meldungen der letzten 24 Stunden durchsuchen und das Ergebnis als Local-Check-Zeile ausgeben. 


FEHLERMUSTER = re.compile(
    r"computation error|compute error|aborted|exited with zero status but no 'finished' file|"
    r"process exited with code [1-9]|too many (exit|error)|disk usage limit exceeded",
    re.IGNORECASE,
)

fehler = 0
for zeile in cmd("--get_messages").splitlines():
    m = re.match(r"\d+: (\d{2}-\w{3}-\d{4} \d{2}:\d{2}:\d{2}) ", zeile)
    if not m:
        continue
    t = datetime.strptime(m.group(1), "%d-%b-%Y %H:%M:%S").timestamp()
    if jetzt - t <= 86400 and FEHLERMUSTER.search(zeile):
        fehler += 1

st = 2 if fehler >= 3 else 1 if fehler >= 1 else 0
print(f'{st} "BOINC Fehler 24h" fehler={fehler};1;3 {fehler} Fehlermeldungen in 24 h')

boinccmd muss im BOINC-Datenordner laufen, weil es dort das Passwort für die Steuerung findet (gui_rpc_auth.cfg). Das Skript wechselt deshalb vorher nach /var/lib/boinc-client. Das ganze Skript und eine Fassung für Windows (PowerShell) stehen unten zum Herunterladen.

Einrichten Schritt für Schritt

1. Agent installieren. Checkmk liefert passende Pakete selbst aus, damit Agent und Server dieselbe Version haben:


curl -fsS -o agent.deb http://<checkmk-server>/<site>/check_mk/agents/check-mk-agent_<version>-1_all.deb
sudo dpkg -i agent.deb

2. Skript ablegen und ausführbar machen, dann einmal von Hand testen:


sudo install -m 755 boinc /usr/lib/check_mk_agent/local/boinc
sudo /usr/lib/check_mk_agent/local/boinc

3. Agent beim Server anmelden, damit die Verbindung verschlüsselt läuft:


sudo cmk-agent-ctl register --hostname <hostname> --server <checkmk-server>:8000 \
     --site <site> --user <automation-benutzer> --trust-cert

4. In Checkmk beim Host „Checkmk agent“ statt „No agent“ einstellen, die Dienste erkennen lassen (Service discovery) und die Änderungen aktivieren. Die vier BOINC-Dienste erscheinen dann wie jeder andere Dienst.

Unter Windows ist es dasselbe Prinzip: Agent per MSI-Paket installieren, das PowerShell-Skript nach C:\ProgramData\checkmk\agent\local\boinc.ps1 legen und mit cmk-agent-ctl.exe register anmelden. BOINC liegt dort unter C:\Program Files\BOINC, die Daten unter C:\ProgramData\BOINC.

Ergebnis: Der erste Alarm kam sofort

Kaum war der Check auf dem betroffenen Rechner eingerichtet, stand „BOINC Fehler 24h“ auf kritisch: 20 Fehlermeldungen in 24 Stunden, alle von der Endlosschleife am Morgen. Genau das hätte drei Tage früher auffallen sollen. Weil die Ursache schon behoben war, habe ich den Alarm quittiert. Nach 24 Stunden wird der Dienst von selbst wieder grün.

Beifang: drei Fehlalarme und eine echte Warnung

Mit dem Agenten kommen auch alle normalen Systemdienste in die Überwachung – und damit ein paar Überraschungen:

  • CVMFS-Dateisysteme mit 100 % Inodes: LHC@home lädt seine Software über CVMFS. Dieses FUSE-Dateisystem meldet technisch bedingt immer 0 freie Inodes. Eine Regel „Disabled services“ für Filesystem /cvmfs/ blendet die Dienste aus.
  • Abstürze von cvmfs2: Jedes Mal, wenn autofs ein CVMFS-Repository nach fünf Minuten Ruhe aushängte, stürzte cvmfs2 dabei ab – harmlos, aber jedes Mal mit einem Absturzbericht. Mit --timeout=0 in der autofs-Konfiguration bleibt CVMFS eingehängt.
  • Fehlgeschlagene Systemdienste: Der Absturzmelder einer Desktop-Umgebung versuchte jeden dieser Berichte an einen angemeldeten Benutzer zu schicken. Auf einem Rechner ohne Desktop geht das nicht. Er ist jetzt abgeschaltet.
  • Echte Warnung – CPU-Temperatur: Ein Server erreichte nach einer Erhöhung der BOINC-Last 81 °C. Gedrosselt hatte er noch nicht, ich habe die Last trotzdem wieder etwas gesenkt.

Download

boinc-checkmk-check.zip – Local Check für Linux (boinc, Python 3) und Windows (boinc.ps1, PowerShell). Schwellen und Pfade stehen oben im Skript und lassen sich leicht anpassen.

Fazit

Ein Local Check ist der schnellste Weg, etwas in Checkmk zu überwachen, für das es kein fertiges Plugin gibt: ein paar Zeilen Skript, eine Zeile Ausgabe pro Dienst. Für BOINC heißt das: Ich sehe sofort, wenn ein Rechner Fehler produziert oder still steht – statt es erst nach Tagen an einer Aufgabe zu merken, die nicht fertig wird.