Da SNMP bei manchen Systemen teilweise funktioniert und ich nicht sicher bin, ob das ein BUG in Checkmk ist oder in dem zu überwachenden System, möchte ich das System über den Syslog überwachen.
Das System bietet einen zu konfigurierenden Syslog Server. Die Weiterleitung zu der CMK EC funktioniert auch gut.
ich würde allerdings, gerne die EC als check in Monitoring haben, sodass ich nur darüber das System überwache… hierzu habe ich die folgende Regel erstellt und es meinem System zugewiesen.
der Check wird wie unten angezeigt erstellt… jedoch immer auf OK. Wenn ich ein Testlog kreiere… bekomme ich die Benachrichtung in EC jeodch taucht das nicht im Check auf.
Hi @ymez, so weit sieht das ja gut aus. Der Events Service nimmt immer den Status der Events in der EC an. Das heißt, wenn das schlechteste Event in der EC OK ist, bleibt der Service OK. Erst bei WARN, respektive CRIT ändert sich der Status. Weiterhin kann es auch sein, dass der Hostname bzw. die IP nicht matched, hast du das gegengeprüft?
Hallo Robin,
Danke für die Hilfe.Das matching macht aktuell Probleme.
ich habe zwei Regeln erstellt, jeweils für den entsprechenden Host. erstmal ohne Matching Creteria…gar nix.
ich dachte, da die zweite Regel irwie alles durchlässt… hat sie vllt mehr Gewicht und übernimmt das Matching also habe ich die zweite Regel konfiguriert.
wenn ich die zweite Regel Syslog_xClarity auf den anderen zweiten Host matche, dann bekomme ich für den ersten Host keine Events mehr… was auch richtig ist(in Bezug auf die zweite Regel). aber wieso funkt die erste Regel LENOVO… nicht…?
Hi Ymes.
Ich denke das sieht soweit gut aus. Wenn ich dich richtig verstehe, möchtest du , dass das erste Event z.B. Warning von einen OK Event überschrieben wird, damit deine EC Überwachungsregel funktioniert.
Hier ist es wichtig zu verstehen, wie die EC ein Event als eindeutig beschreibt.
Diue Eindeutigkeit geht aus den folgenden Hauptfeldern hervor:
Hostname
Application
Sind die beiden Felder schon mal gleich, können Regeln wie Counting angewendet werden.
Diese Hauptfelder können durch die Matching Groups erweiteret werden, denn diese fließen dann auch bei der Korrelation ein. Hier ein Beispiel:
Match: ^.* (0.123) .*
Gebildeter Schlüssel: Hostname Application 0.123
Alle Ereignisse, die diese Werte enthalten können korreliert werden (Counter, Status, usw.).
Ich hoffe das hilft dir weiter.
Kann es sein, dass Du Hardware Monitoring von Lenovo Server machen möchtest?
Ich kann Dir da IPMI wärmstens empfehlen. Wir überwachen damit hunderte Server ohne Probleme. Das ganze ist Hersteller und Modell unabhängig. Wir haben von alten IBM M3 bis LENOVO SR670 und DELL DRAC implementiert. Du musst Dich auch nicht um irgendwelche Schwellwerte kümmern da die der Hersteller schon entsprechend auf dem BMC eingestellt hat. Darüber hinaus geht das Monitoring auch wenn das OS nicht abgestürzt ist. Da muss man nicht lange nach dem Fehler suchen und kann schnell das passende Ersatzteil ordern.
Ich hoffe das hilft
So ganz habe ich Dein Problem mit der EC noch nicht erfasst.
Evtl. wäre ein Dump der eigentlichen SYSLOG Messages hilfreich.
es funktioniert allerdings nur, wenn die Regel in EC ohne matching criteria eingerichtet ist.
solage ich mehrere Regel erstelle und sie jeweils den entsprechenden Servern zuweise… bekomme ich keine Events mehr. also Das Matching funktioniert nicht richtig.
@robin.gierse
ich konnte das problem lösen, aber ich weiß nicht warum das so ist : folgendes.
ich habe zunächst die “log level” in den EC Configuration auf Critical gesetzt sodass ich die logs in var/log/mkevent.log sehen kann.
Als ich den Test ausgelöst habe habe ich folgede Einträge bekommen.
application: StorageArray
core_host: None
facility: 3
host: 10.10.10.2
host_in_downtime: False
ipaddress: 127.10.2.30
pid: 0
priority: 1
text: Test syslog message from system name: STO-LENOVO02
time: 1661317400.0
im punkt host, ist die IP des Systems, das die logs an checkmk sendet. also STO-LENOVO02
und in ipaddress: das ist die Firewall. Und als ich das Matching so konfiguriert habe. habe ich auch dann die Events bekommen vom Host. sehr merkwürdig.
Nein, das ist das syslog Protokoll, bzw. die Firewall.
Checkmk macht nichts, außer die IP zu nehmen, die im entsprechenden Feld steht.
Wenn eure Firewall das überschreibt, bekommst du genau den beschriebenen Effekt.
Fürs Troubleshouting muss man die “Debug Rule Execution” in EC aktivieren und auf dem Checkmk Server live mit “tail -f ~/var/log/mkeventd.log” die Ingoing Syslogs in Auge behalten, dann aus dem betroffenen Hostsystem einen Testlog regenerieren und dann prüfen was in ~/var/log/mkeventd.log unter sourceip und host steht…
Ich habe Deine Antwort als Lösung markiert, da du mir den Tipp gegeben hast wegen matched hosts und ip. Danke dafür.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
Aber eine komplette Syslog Message wäre dennoch hilfreich.
