Kein Empfang von SNMP-Traps in Event Console

Hallo,
ich möchte gern SNMP-Traps von diversen Devices im Checkmk (v1.6.0p11) empfangen und in der Event Console darstellen.
Ich habe alles gemäß Handbuch eingerichtet. Der betroffene Checkmk-Server ist ein Slave, dessen Monitoring-Config vom Master-Server gepushed wird.

Ein lokaler Test mit einem manuell erzeugten Trap per snmptrap funktioniert. Er landet sofort in der Event Console. Aber mehr passiert leider nicht.
Es kommen laut tcpdump viele Traps von anderen Devices auf dem Checkmk-Server an:
14:08:19.871995 IP 172.xx.xx.xx.snmp > nk-mon01.46651: C=“xxxxxx” GetResponse(229) system.sysObjectID.0=E:cisco.1.2137 system.sysUpTime.0=1381613674 system.sysContact.0="" system.sysName.0=“xxxx.xxxx.xxxx” system.sysLocation.0="" system.sysServices.0=6 system.8.0=0 system.9.1.2.1=E:cisco.7.129 system.9.1.2.2=E:cisco.7.115 system.9.1.2.3=E:cisco.7.265
Aber es landet nichts in der Event Console.
Leider kann ich einen manuellen Trap-Test von einem remote Server aus nicht machen, weil es keinen weiteren Linux-Server in der Umgebung gibt (außer den Checkmk-Server).

Ich habe 2 Checkmk-Regeln angelegt, die aus meiner Sicht passen müßten:

Und eine Rule in einem Event Pack:


Das SNMP-Trap-Debugging habe ich aktiviert. Aber ins mkeventd.log wird nichts reingeschrieben. Ein Eintrag á la “2020-05-29 11:29:18,237 [15] [cmk.mkeventd.EventServer.snmp] Trap received from 127.0.0.1:36488. Checking for acceptance now.” fehlt.
Es kann also auch nicht an fehlenden MIBs liegen, weil ja dann im Log wenigstens der Empfang des Traps und die mangelnde Translation protokolliert würde.

Jetzt habe ich keine Idee mehr, woran es liegen könnte.
Kann jemand helfen?

Vielen Dank,
Antje

Hallo Antje,

passt die SNMP-Community?

Die kann in den Einstellungen der Event Console ergänzt werden, wenn sie nicht “public” sein sollte.

Hallo Robert,
ja, das habe ich schon gecheckt. Man muß ja die Community auch in den Event Console Settings definieren (wenn sie von public abweicht). Das habe ich gemacht.
Hat es vielleicht etwas mit dem verteilten Monitoring zu tun?

VG
Antje

Vielleicht liegt es auch an den Einstellungen in unserer verteilten Checkmk-Umgebung.
Wir haben einen Master und mehrere Slaves. Die Master-Konfig wird auf alle Slaves gepushed. WATO-Einstellungen sind nur auf dem Master erlaubt.
Die Devices, die vom Slave überwacht werden, senden ihre Traps an den Slave. Wie muß ich die Event Console Settings und die Site specific settings nun setzen, damit die Traps vom Slave zum Master in die globale (und einzige) Event Console kommen? Die Beschreibung im Online-Handbuch finde ich leider nicht sehr hilfreich.

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:

  1. Aktivieren des SNMP-Trap-Versands
  2. Definition des lokalen (Slave) Checkmk-Servers als Trap-Sink
  3. Festlegen einer Community
  4. Sicherstellen, daß UDP-Pakete via Port 162 vom Host zum Checkmk-Server versendet werden können

Auf dem Slave Checkmk-Server:

  1. Deaktivieren der SELinux-Funktionen in /etc/sysconfig/selinux
  2. Deaktivieren und und Stoppen des SNMPTrap-Daemons:
    systemctl disable snmptrapd
    systemctl stop snmptrapd
  3. 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
  4. Checkmk muß für den Empfang von SNMP-Traps konfiguriert werden:
    omd config
  5. Unter “Addon” werden alle MKEVENTD-Funktionen aktiviert.
    grafik
  6. Nach einem Neustart der Site sind die Änderungen gesetzt.
  7. 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:
    grafik
  8. Anschließend geht man in die Site specific settings der Site (Zahnrad mit grünem Stift). Dort sind einige Einstellungen zu setzen:
  9. Kategorie “Event Console: Generic”:
    Replication from a master muß deaktiviert sein:
    grafik
    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).
    grafik
    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:
    grafik
    Die Trap Translation kann man vorerst deaktiviert lassen und später einschalten.

Auf dem Master Checkmk-Server:

  1. 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”:
    grafik
  2. 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”:
    grafik
  3. Hier sollte man die Einstellungen mal durchgehen, muß aber nicht zwingend Anpassungen vornehmen. Die Option “Access to event status via TCP” wird nicht gesetzt:
    grafik
  4. 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”:
    grafik
  5. Hier legt man eine Check event state in Event Console-Regel an:
    grafik
    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.
  6. Anschließend geht man wieder im WATO zur “Event Console” und erstellt dort ein neues Rule Pack zur Verarbeitung der ankommenden Events:
    grafik
  7. Im neuen Rule Package erzeugt man dann eine oder mehrere Regeln:
    grafik
  8. 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:
    grafik
  9. 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”.
    grafik
    Das erzeugte Testevent sollte dann in der Event Console zu sehen sein:
    grafik
  10. 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:
    grafik

Viele Grüße,
Antje

4 Likes

Unter The Event Console - Processing logs and SNMP traps steht bisschen was zu Traps. Habe es selbst noch nicht durchgelesen (weil bei uns bisher Traps nicht genutzt werden), aber auf jeden Fall schonmal Danke für diesen ausführlichen Artikel!

Wenn das über die Inhalte im Handbuch hinaus hilfreich ist, wäre es vielleicht als eigener Blog-Artikel gut aufgehoben? Sozusagen als “Teil 2” zu https://blog.checkmk.com/de/network-monitoring-with-snmp-a-necessary-evil
Siehe auch https://go.checkmk.com/submit-your-idea

Gruß
Martin

Hallo Martin,

danke für Dein positives Feedback und Deine Tips.
Die genannte Webseite über Traps hatte ich für meine Recherchen auch zu Rate gezogen. Ich wollte unbedingt noch den Weg der Traps über die Event Console ausprobieren. :slight_smile:

Falls wir das mit dem Trap-Empfang irgendwann noch hinbekommen :grimacing:, denke ich gern mal über einen Blog-Artikel oder ähnliches nach. Es hilft sicher auch anderen in größeren verteilten Umgebungen. :+1:

Danke und viele Grüße,
Antje

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.