vorab an alle beteiligte Personen (vor allem Jens Maus und Alexander Reinert) zum Thema und
noch mal Vielen Dank für eure unermüdliche Arbeit.
Ich selbst habe check_mk in der Version 1.5.0p2 auf einem SBC (Odroid HC1) laufen und
meine Homatic Steuerung (RM 3.45.7.*) nebst check_mk AddOn 1.3 am laufen.
- Screenshot von check_mk GUI des RasberyMatic Hosts
(in der Hoffnung es interessiert auch noch andere).
Bei dem Herumspielen mit der check_mk Konfiguration sind mir so einige (teilweise bekannte) Dinge aufgetreten.
- ntpd vs. chrony Check: Diese Änderung wurde bereits hier im Forum angesprochen.
Ich habe sie auch durch einfaches Editieren der Datei server.tcl beheben können. Bleibt hier nur noch die Änderung auch noch in github zu verewigen.
- Wenn man das check_mk AddOn über die Web GUI neu durchstartet, entsteht ein Fehler
bei dem Aufruf von dem Kommando: ip link.
Ursache ist der Umstand, dass in der Environment Variable PATH der Pfad /sbin nicht enthalten ist.
Bei dem kompletten Neustart des RasberryMatic tritt der Fehler nicht mehr auf!?
Lösung war hier die Angabe des kompletten Pfades bei dem Aufruf des Kommandos
(siehe auch server.tcl.patch.txt).
- Bei der Fehlersuche und damit verbundenem Neustart des check_mk AddOns blieb manchmal die Web GUI hängen.
Der Dialog für die Meldungen nach dem Neustart kam manchmal gar nicht oder stark verzögert.
Das scheint aber normal zu sein, da hier offenbar keine asynchrone Arbeitsweise vorliegt.
- Zur Angleichung an den RM Standard habe ich den Pfad für die PID Datei mal angepasst
(siehe auch in ).
- dem Auslesen und automatische Übernahme des Loglevel aus der RM WebGUI
Hintergrund des Gedankens ist die Tatsache, dass ich im Syslog auf den Verbindungsstatus von check_mk verzichten kann.
Eventuell kann man in der Web GUI vom check_mk AddOn das sogar konfigurierbar machen ...
- Aktivierung der xinetd Konfiguration (Sicherheitsaspekt).
- Umstellung des check_mk AddOns auf die originale check_mk Agent Struktur und
Implementierung des Homatic Anteils als check_mk Agent Plugin.
Das hätte den Charme, dass alle bereits existierenden Checks von check_mk einsetzbar sind.
- Einbindung beziehungsweise Übernahme der monit Konfiguration in check_mk.
Wenn die Standard check_mk Struktur umgesetzt wird, hat sich dieser Punkt fast von selbst erledigt,
da via lokalem Event Monitoring des check_mk Agent Log Plugins alle monit Meldungen aus dem syslog gefiltert werden können.
Mit freundlichen Grüßen
Gernot