Wir nutzen CheckMK für das Monitoring von mehreren hundert Netzgeräten.
Um mich an der Sache ein wenig auszuprobieren, wurde mir eine Testinstanz zur Verfügung gestellt.
Diese läuft auf dem System, auf dem auch das Produktivsystem bzw. die Produktivinstanz aktiv ist.
Meine Instanz befindet sich im Ordner omd/sites/name.
ich habe ein kleines Pythonscript geschrieben, welches eine bestimmte Webseite crawled und Informationen daraus extrahiert.
Diese werden dann im Format:
0 Name - OK: Bla Bla
0 Name - OK: Bla Bla
2 Name - CRIT: Bla Bla
1 Name - WARN: Bla Bla
via print je Zeile ausgegeben.
Nun habe ich aber das Problem, dass dieses Script sich nicht auf einen bestimmten Hosts bezieht.
Vielmehr möchte ich die Ausgabe des Scripts einfach in einem iFrame in einem Dashboard angezeigt bekommen.
Das Script sollte in einem bestimmten Zyklus ausgeführt werden.
Demetnsprechend sollten sich die Infos in der View dann auch ändern.
Ist etwas in dieser Art möglich?
in welchem Ordner muss das Script liegen?
Wie muss CheckMK zur Implementierung der Informationen konfiguriert werden?
ich habe ledglich Zugriff auf die Ordnerstruktur unterhalb meiner OMD Instanz.
Ich würde mich freuen wenn mir jemand diesbzgl. einen Tip geben kann.
Ich danke euch.
Da checkmk von nagios abgeleitet ist, muss ein Service Check immer einem Host zugeordnet werden. In Deinem Fall würde ich einen Dummy-Host einrichten, der als Host-Check-Command “Always assumed to be up” bekommt.
Du scheinst einen Local Check geschrieben zu haben, der immer von einem Agenten aus gestartet wird. Das ist in dem Fall nicht unbedingt hilfreich.
Aus dem Local Check kannst Du aber ganz einfach ein Agenten-Plugin machen, indem Du als Prolog “<<<<dummyhostname>>>>\n<<<local>>>” und als Epilog “<<<<>>>>” ausgibst. Das Agenten-Plugin dann einfach auf dem Monitoring-Server in /usr/lib/check_mk_agent/plugins ablegen. Die Local Checks werden dann per Piggyback-Verfahren dem Dummy-Host zugeordnet.
vielen Dank für deine Antwort.
Ich habe das ausprobiert aber es scheint noch Probleme zu geben.
Das Python Script printed den folgenden Output:
OMD[instanzname]:/usr/lib/check_mk_agent/plugins$ ./test.py <<<<dummyhost>>>> <<<local>>> 0 Name - OK: Bla Bla 0 Name - OK: Bla Bla 2 Name - CRIT: Bla Bla 1 Name - WARN: Bla Bla <<<<>>>>
Der Hostname des dummyhosts ist “dummyhost” wie im Script angegeben.
Dennoch meldet der “Full Scan” unter “Services”:
Starting job...
+ FETCHING DATA
[piggyback] Execute data source
No piggyback files for 'dummyhost'. Skip processing.
hat jemand eine Idee wo mein Fehler liegen könnte?
Ich danke im Vorraus für die Hilfe.
Hallo r.sander,
ich fürchte, ich verstehe die Frage nicht.
Ich habe auf einer völlig nackten Site lediglich diesen einen “dummyhost” eingerichtet. Und ihm als Host-Check-Command “Always assumed to be up” gegeben. Mehr hab ich mit der gesamten Site noch nicht angestellt. Diese Site ist auch eigentlich nur zum rumspielen für mich gedacht.
Ich tippe dass der Pfad /usr/lib/check_mk_agent/plugins nicht korrekt sein könnte weil man je Instanz jeweils eigene Ordnerstrukturen verwendet?
Allerdings kann ich unterhalb von /OMD/Sitename keine Ordnerstruktur finden die so oder so ähnlich aussieht.
“Name” ist jeweils unterschiedlich. Sorry. Das wurde aus dem editierten Output nicht ganz klar.
Da der “Full Scan” aber angibt erst gar keine Piggyback Files zu finden, hätte das erst in 2. Instanz ein Problem werden dürfen, wenn ich da was verhauen hätte
/usr/lib/check_mk_agent ist teil der Agenteninstallation auf dem Host. Wenn dort auch die Site läuft, ist das also der Monitoring-Server.
Damit checkmk die von diesem Agenten bereitgestellten Daten verarbeiten kann, muss es den Agenten abfragen. Du musst also den Monitoring-Server mit ins Monitoring aufnehmen.
Ich danke dir für deine Hilfe.
jetzt ist mir die Ordnerstruktur klar geworden.
Ich habe geglaubt, dass die Ordner unterhalb von /usr/lib/check_mk_agent ebenfalls zum Monitoring Server gehören.
Offenbar gehört diese Ordnerstruktur aber zu dem Agent welcher das Monitoringsystem selbst überwacht.
Wenn ich den Monitoring Server im Interface als Host hinzufüge und das Script in den Pluginsordner lege, funktioniert nun auch die Ausgabe.
Allerdings scheint mir das keine elegante Lösung zu sein.
Der Piggyback Output hat nichts mit dem Host “Monitoring Server” zu tun, außer der Tatsache das dieser das Script beherbergt ,die Webseite crawled und die gewünschten Informationen bereit stellt.
Wollte ich nun z.B. einen Check schreiben welcher das aktuelle Wetter bzw. die aktuelle Temperatur an Ort X ausgibt, weil diese Information für mein Monitoring relevant ist und würde ich dafür eine Wetterseite crawlen, käme man ja auch nicht auf die Idee diese Information mit dem Monitoring Host in Verbindung zu bringen.
Die Idee dass z.B. ein dummyhost ohne IP erstellt wird, welcher lediglich die Aufgabe hat die gewünschten Informationen bereit zu stellen, gefällt mir deutlich besser.
Welche Art von Check macht an dieser Stelle am ehesten Sinn?
jegliche Dokumentation die ich zu diesem Thema finden kann bezieht sich i.d.R. auf einen realen Host.
Ein Nagios-Plugin in $OMD_ROOT/local/lib/nagios/plugins ablegen und über den Regelsatz “Classical active and passive monitoring checks” einbinden. Für jeden Service Check braucht es dann eine Regel in diesem Regelsatz, um das Nagios-Plugin korrekt zu parametrisieren.
Ein Datasource-Program, das im Prinzip einfach die Ausgabe Deines jetzigen Skriptes generiert, ohne die Piggyback-Header mit den vier spitzen Klammern. Das wird dann dem Dummy-Host statt eines normalen Agentenzugriffs zugewiesen. Der Dummy-Host darf dann genau nicht auf “No agent” stehen. Datasource programs - Monitoring devices without access to an operating system
Ich hatte ursprünglich das Agenten-Plugin mit den Piggyback-Daten empfohlen, weil ich davon ausging, dass der Monitoring-Server eh überwacht wird. Das wäre dann die einfachste Möglichkeit.
