Dieses Problem hat sich insofern gelöst, daß sich herausgestellt hat, daß unser Checkmk-Server nicht wirklich SNMP-Traps empfängt. Die Einträge des tcpdumps stammen von den Bulkwalk-Requests (Port 161). Daher hat dies nichts mit den Event Console-Einstellungen im Checkmk zu tun.
Nichtsdestotrotz habe ich in unserem Checkmk die Event Console/n so konfigurieren können, daß alle Events in einer großen verteilten Umgebung zentral eingesammelt und angezeigt werden. Ziel ist es also, daß die von den Slave-Servern überwachten Systeme SNMP-Traps an den lokalen Slave-Server senden, diese empfangen und verarbeitet und zur zentralen Master Event Console auf dem Master-Checkmk Server repliziert werden. Weil die Informationen im Handbuch dazu sehr rudimentär sind, habe ich mal selbst eine kleine Anleitung dazu verfaßt. Sie ist sicher nicht perfekt und an einigen Stellen noch nicht rund, aber vielleicht auch für andere hilfreich. Bei uns funktioniert es so.
Voraussetzungen:
Administrativer Zugang zur Checkmk-GUI (WATO), auf die Linux-Server der Checkmk-Server und auf die zu überwachenden Systeme für die SNMP-Einrichtung
Anleitung (Schritt-für-Schritt)
Auf den zu überwachenden Systemen:
- Aktivieren des SNMP-Trap-Versands
- Definition des lokalen (Slave) Checkmk-Servers als Trap-Sink
- Festlegen einer Community
- Sicherstellen, daß UDP-Pakete via Port 162 vom Host zum Checkmk-Server versendet werden können
Auf dem Slave Checkmk-Server:
- Deaktivieren der SELinux-Funktionen in /etc/sysconfig/selinux
- Deaktivieren und und Stoppen des SNMPTrap-Daemons:
systemctl disable snmptrapd
systemctl stop snmptrapd - Prüfen, ob eine lokale Firewall läuft und wenn ja, dann erlauben, daß der Host UDP-Pakete von Hosts per Port 162 empfangen darf
- Checkmk muß für den Empfang von SNMP-Traps konfiguriert werden:
omd config - Unter “Addon” werden alle MKEVENTD-Funktionen aktiviert.
- Nach einem Neustart der Site sind die Änderungen gesetzt.
- Auf der GUI des Master Checkmk geht man als nächstes in die WATO-Einstellungen nach “Distributed Monitoring”.
Man geht in die Properties der Site-Verbindung (grüner Stift) und stellt sicher, daß diese beiden Optionen aktiviert sind:
- Anschließend geht man in die Site specific settings der Site (Zahnrad mit grünem Stift). Dort sind einige Einstellungen zu setzen:
- Kategorie “Event Console: Generic”:
Replication from a master muß deaktiviert sein:
Access to event status via TCP ist zu aktivieren. Man wählt einen Port auf dem Slave-Server der noch nicht vergeben ist. Also vorher unbedingt prüfen, auf welchem Port der Livestatus läuft!
Es muß natürlich außerdem geprüft werden, ob eine Verbindung vom Master Checkmk zum Slave Server über diesen Port möglich ist (Firewall).
Kategorie “Event Console: SNMP Traps”:
Bei den Credentials for processing SNMP Traps ist die Community zu setzen, mit der die Traps am Slave Server ankommen:
Die Trap Translation kann man vorerst deaktiviert lassen und später einschalten.
Auf dem Master Checkmk-Server:
- Auch das Master Checkmk wurde mit omd config so konfiguriert, daß es SNMP-Traps erhalten kann (siehe Punkte 4 und 5 beim Slave Server oben)
Prüfen läßt sich das im WATO in den Global Settings unter “Site Management”:
- Als nächstes konfiguriert man die Master Event Console. Dafür gibt es im WATO ein eigenes Menü “Event Console”. Darin gibt es oben den Punkt “Settings”:
- Hier sollte man die Einstellungen mal durchgehen, muß aber nicht zwingend Anpassungen vornehmen. Die Option “Access to event status via TCP” wird nicht gesetzt:
- Abschließend sind Rules zu definieren, damit die Events eingesammelt bzw. abgefragt und verarbeitet werden. Die erste Regel erstellt man im WATO unter “Host & Service Parameters” in der Kategorie “Event Console”:
- Hier legt man eine Check event state in Event Console-Regel an:
Diese Regel hat keine Bedingungen, wichtig ist aber, daß die Option “Access to the Event Console” auf den Wert “Connect to the local Event Console” gesetzt ist!
Damit stellt man sicher, daß die Events von den Slave Servern abgefragt und zentral eingesammelt werden. - Anschließend geht man wieder im WATO zur “Event Console” und erstellt dort ein neues Rule Pack zur Verarbeitung der ankommenden Events:
- Im neuen Rule Package erzeugt man dann eine oder mehrere Regeln:
- Darin legt man dann alle Bedingungen und Aktionen fest, die beim Eintreffen von Syslog-Meldungen oder SNMP-Traps erfolgen sollen, um diese zu verarbeiten. Will man erst einmal alle Events einfangen, setzt man anfangs weniger Match-Kriterien und verfeinert die Regel/n nach und nach:
- Die Funktionalität der Regeln kann man im Event Simulator testen. Allerdings ist das nur ein Test für Syslog-Meldungen, nicht für SNMP-Traps. Hierzu füllt man die Felder mit Testdaten aus und klickt anschließend auf die Buttons “Try out” und “Generate Event”.
Das erzeugte Testevent sollte dann in der Event Console zu sehen sein:
- Ein Test mit einem SNMP-Trap kann durch folgenden Befehl beispielhaft auf einem Linux-System erzeugt werden:
snmptrap -v 1 -c ‘.1.3.6.1.6.3.1.1.5.3’ ‘0.0.0.0’ 6 33 ‘55’ .1.3.6.1.6.3.1.1.5.3 s “teststring000”
Das entsprechende Event sieht dann in der Event Console so aus:
Viele Grüße,
Antje