Unsere EventDB gehört ja mittlerweile bei vielen Monitoringsystemen zur Grundausstattung sobald Syslog oder SNMP Traps ins Spiel kommen. Oft kam hier die Frage: “Kann ich damit auch gleiche Events zusammenfassen und automatisch Acknowledgen sobald ein passendes Clear Event kommt?”. Bisher musste ich immer beschämt sagen, dass wir so etwas geplant, aber noch nicht umgesetzt haben.
Ab heute ändert sich das – der EDBC ist in der ersten Beta da. Und mit ihm wird nicht ‘nur’ oben genanntes Szenario abgedeckt, sondern ein sehr mächtiges Werkzeug bereitgestellt um Nachrichten und Traps in ein Monitoringsystem einzubinden.
Die Hauptfeatures, die der EDBC derzeit bietet:

  • Empfangen von Ereignissen via Pipe, SNMP Handler und/oder Mail
  • Persistieren von Ereignissen in die EventDB, ggf. Vorfiltern der Ereignisse nach beliebigen Merkmalen (u.a. Netzwersegmente, OIDs, Teilstrings)
  • Erkennen logisch gleichartiger Events anhand von Feldwerten, Netzwerksegmenten, Teilstrings (via Regexp Gruppen), etc.
  • Zusammenfassen logisch gleichartiger Events
  • Erkennen von Clear Events und ggf. Acknowledgen aller zugehörigen Problemevents in der EventDB
  • Senden von Icinga/Nagios Kommandos bei bestimmten Events (…auch abhängig davon ob es ein neues Problem, ein bereits bekanntes Problem oder ein Clear event ist)
  • Einfache Erweiterbarkeit mit rudimentären Python Kenntnissen


Die zwei Grundbausteine des EDBC sind Rezeptoren und Prozessoren, welche beliebig miteinander verkettet werden können (sog. Chains). Diese sind für sich einfach konfigurierbar (und ist bei der Installation schon so weit Vorkonfiguriert, dass nur noch Anpassungen notwendig sind), dazu sehr gut dokumentiert und machen den EDBC in der Kombination extrem flexibel.

  • Rezeptoren übernehmen die Rolle des Agenten und empfangen Nachrichten von der Aussenwelt. Zwei Beispiele:
    • Der PipeReceptor erstellt eine Pipe und generiert Events aus Nachrichten, die in diese Pipe geschrieben werden (welches Format die Nachrichten haben lässt sich dabei frei Konfigurieren)
    • Der SNMPReceptor ist das Equivalent zum SNMPTT, d.h. er empfängt und formatiert SNMP Traps. Da man das Rad nicht immer neu erfinden muss werden hier die von snmpttconvertmib erstellten SNMPTT Konfigurationen verwendet, ein Wechsel von SNMPTT ist daher recht simpel.
  • Prozessoren arbeiten mit den Events und können verschiedenste Aufgaben erfüllen, auch hier ein paar Beispiele:
    • Aggregationsprozessoren erlauben es, Regeln zu definieren, welche Events zusammengefasst werden sollen, welche Events als clear Events gelten, etc.
    • Commandprozessoren schicken direkt Befehle an die Nagios/Icinga Kommandpipe (z.B: “remove Acknoweldgement” bei einem neuen Problem)
    • Und auch das schreiben eines Events in die Datenbank ist auch als Prozessor umgesetzt – d.h. man kann den EDBC auch ohne Datenbank betreiben wenn man will ( z.B. um Events direkt in passive Checkergebnisse umzuwandeln)
  • Chains verknüpfen das ganze. Zu Beginn einer Chain steht immer ein Rezeptor gefolgt von einer Reihe Prozessoren. Eine Chain kann z.B. so aussehen:

Alle Features des EDBC zu beschreiben würde jetzt jedoch einen einfachen Blogpost sprengen, in der ausführlichen Dokumentation findet sich aber ein Schritt für Schritt Tutorial, welches einem die verschiedenen Szenarien und Anwendungsfälle näher bringt und auch näher auf die Features eingeht.
Zusätzlich dazu gibt es einen neuen EventDB Beta Release, der neben einigen Bugfixes und der EDBC Unterstützung auch experimentellen PostgreSQL Support mitbringt.
Zu finden sind beide Pakete unter netways.org (EventDB, EDBC) oder in unserem GIT Repository.