def discover_jitsi_meet(section):
for sector, used, slots in section:
yield Service(item=sector)
def check_linux_jitsi(item, section):
for sector, used, slots in section:
if sector == item:
used = int(used) # convert string to int
slots = int(slots) # convert string to int
if used == slots:
s = State.CRIT
elif slots - used <= 10:
s = State.WARN
else:
s = State.OK
yield Result(
state = s,
summary = f"Used {used} out of {slots} slots")
return
Das was das Script ausgibt ist ja ein local Check da wird kein extra Check auf CMK Seite gebraucht.
Oder sollte dein Check Plugin für eine andere Ausgabe sein?
Wenn ja wäre es gut diese zu sehen und auch den Code in einen vorformatierten Rahmen zu packen so wie gerade ist das echt übel zu lesen
Was an deinem Plugin erstmal nicht funktionieren wird ist die Behandlung der Daten. Du gehst einfach davon aus, dass in der “Section” einfach drei Werte stehen, das glaube ich eher nicht.
Genau aus dem Grund kann man nur was sagen wenn auch der Output vom Plugin vorhanden ist.
Du merkst ja, dass ich mich noch nicht so richtig mit den Check-Plugin-programmieren auskenne.
Ich habe versucht, was aus der Docu abzubilden. Na das ging ja logisch in die Hose, da die Daten ja in allen möglichen Formaten ausgegeben werden können.
Also das Agenten-Plugin auf dem Jitsi-Server erzeugt folgende Ausgabe:
1._und 2. Zeile habe ich jetzt mal zur Erläuterung dazu gefügt.
Die 2. Zeile ist ohne Umbruch, also alles auf einer Zeile.
Also letztendlich nur zwei Zeilen.
Ich habe das Plugin auch nur gefunden/kopiert. Keine Ahnung warum die Struktur so gewählt ist.
Man könnte die Ausgabe evt. auch anpassen.
Danke für den Link! Das ist ein local check, gehört also als ausführbare Datei (oder symlink wie im Playbook vorgeschlagen) auf dem Client unter /usr/lib/check_mk_agent/local/. Ausgabe des Checks selbst ist dann eine einzelne Zeile pro Service, Details siehe Local checks.
Diese Ausgabe wird dann vom Agent im Abschnitt <<<local>>> mit ausgeliefert und sollte in der Service Discovery auftauchen.
Mir ist grad nicht klar, wo die von dir zitierte Ausgabe <<< Jitsi >>> herkommen soll.
Du kannst den local check auch manuell ausführen und schauen ob/was er zurückliefert. Oder sogar erstmal nur die curl-Aufrufe manuell testen. Evtl muss der Port angepasst und/oder die interne Statistik-API in JiCoFo überhaupt erst aktiviert werden:
Aber ich benötige doch noch die CHECK-Funktion. (auf den Checkmk-Server) ### 2.8. Die Check-Funktion schreiben Somit können wir nun zur eigentlichen Check-Funktion kommen, welche anhand aktueller Agentenausgaben endlich entscheidet, welchen Zustand ein Service annehmen soll. Da unser Check keine Parameter hat und es auch immer nur einen pro Host gibt, wird unsere Funktion ebenfalls mit dem einzigen Argument section aufgerufen…
Ja, ein local check ist so simpel, Details wie gesagt in Lokale Checks
Mit dem Nachteil, dass zB die Limits fix auf Client-Seite im Script stecken statt serverseitig regelbasiert angepasst werden zu können.
Was du da zur CHECK-Funktion zitierst bezieht sich auf vollwertige “native” Check-Plugins statt local checks.
Und ja, der Begriff “plugin” ist in Checkmk etwas überladen und wird an vielen Stellen mit teils abweichender Bedeutung verwendet. Der Zusammenhang ist wichtig
