Weekly Snap: EDBC & EventDB, LCOV & Open Source Survey

weekly snap22 – 26 April released event-monitoring tools, highlighted NSClient++ features and code coverage tools and shared survey results on open source.
Jannis released EDBC 0.1.0 Beta and EventDB 2.0.5 Beta to enable users to automatically recognize ‘clear events’ and acknowledge all related problem events.
Gunnar then discovered LCOV for ‘code coverage’ statistics on C-/C++ programs as Christoph finished the NSClient++ series with part 10 on the latest features worth looking at.
Bernd followed with a presentation on The Future of Open Source from Black Duck Software’s recent survey.
Finally, we welcome Blerim our newest addition to the Managed Services team, while we bid Birger a final farewell, who is finishing his sabbatical and time with NETWAYS.

Release: EDBC 0.1.0beta & EventDB 2.0.5beta

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

(mehr …)

Weekly Snap: PuppetConf, Bacula-Web, EventDB & Check_Open_Problems Plugin

17-21 September covered all our usual topics, from sys admin and developer tips to monitoring tools and talks – with travels to North America thrown in.
As usual, Eva counted down 30 days to the OSMC 2012; this time with Ronny Trommer’s presentation on the status quo of OpenNMS.
Martin then recommended Bacula’s latest web GUI version 5.2.10 and Eric played with VirtualBox command line tools, opening guest applications from his host system.
While Bernd, Julian and Tom looked ahead to next week’s PuppetConf in San Franscisco, Vanessa already sent home happy snaps from her language course in Vancouver.
On the monitoring front, Markus introduced EventDB for event monitoring with Icinga and Thomas put together a new check_open_problems plugin, inspired by our customer Perdata. Both are available on our git.netways.org and Monitoring Exchange.

Ereignis Überwachung mit EventDB und Icinga

Wie jede andere Software hat auch Icinga Grenzen, wo es nur sehr schwer fällt ein Szenario optimal in der Überwachung abzubilden. Icinga ist z.B. darauf ausgelegt den Status eines gewissen Objektes zu überwachen, und wenn dieser gestört ist das zu melden – so lange der Status gestört ist.
Wenn es nun aber um Ereignisse geht, also kein dauerhafter Status, sondern nur eine einmalige Benachrichtung über einen Fehler, fällt es einem recht schwer dies in Icinga einzubauen.
Beispiele für solche Ereignisse:

  • SNMP Traps
  • Syslog
  • MS Eventlog
  • Alarme anderer Überwachungssysteme
  • bestimmte E-Mail Meldungen

Ein Weg dazu ist ein kleines Datenbank Framework namens EventDB.
Die Idee dahinter ist, eine Datenbank zu haben die von verschiedenen Adaptern befüllt wird (dazu reicht grundsätzlich ein simples Datenbankskript) und diese Datenbank dann mit einem Icinga Plugin zu überwachen. Die Überwachung erlaubt Filterung nach Systemname, Schweregrad, Meldungstext und Zeit.
Das Plugin stellt fest dass neue Events vorhanden sind und kann über die normalen Methoden von Icinga den Admin benachrichtigen. Dieser wirft einen Blick in die EventDB über das Webinterface und bestätigt, bzw. bearbeitet die einzelnen Ereignisse. Sobald alle Ereignisse bestätigt sind wird der Servicestatus in Icinga wieder grün.
Beispiel:
Der Switch “switch-3-A” stellt fest, dass Port 12 down ist und sendet einen SNMP Trap an den Icinga Server. Dort empfängt SNMPTT den Trap, verarbeitet die Nachricht und schreibt eine Zeile in die EventDB.
Eine Minute später wird check_eventdb von Icinga ausgeführt, dieser prüft ob für Host “switch-3-A” in den letzten 24 Stunden Events vorliegen, die unacknowledged sind und mindestens Schweregrad “warning” haben. Dies trifft zu und das Plugin meldet Ergebnis WARNING mit einem kurzen Auszug des Events an Icinga zurück.
Der Admin kann nun die Events prüfen und reagieren, der Status springt erst wieder auf OK wenn die betreffenden Events bestätigt sind.
Integration:
Die EventDB kann sowohl ins klassische Webinterface, als auch in Icinga Web integiert werden. So kann man eine direkte Verbindung zwischen der Überwachung und dem Addon schaffen.
Beide Schnittstellen erlauben das Filtern der Suchergebnisse und bearbeiten von Kommentaren und Bestätigungen zu allen Ereignissen.
  
Links und weitere Ressourcen:
EventDB auf netways.de
Wiki und Details auf netways.org (in English)
EventDB Git Repo

Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Logserver mit syslog-ng

Jeder Systemadministrator sollte die Logs seiner Server im Auge haben. Sobald man aber mehr als nur ein paar Systeme administriert, wird man mehr oder weniger von den eingehenden Logs überflutet. Um die Übersicht nicht zu verlieren, kann man die Logs z.B. mit Hilfe von syslog-ng kategoriersieren und filtern. Zusätzlich kann man die Logs zentral auf einem Log-Server speichern. Dies hat den Vorteil, dass die Logdateien der Log-Clients auch zur Verfügung stehen, wenn diese ausfallen.
Die Konfigurationdatei syslog-ng.conf folgt auf den Log-Clients und auf dem Log-Server dem gleichem Schema. Um Log-Nachrichten zu speichern werden drei Bereiche definiert, die Sources (die Quelle der Nachrichten, z.B. /proc/kmsg für Nachrichten vom Kernel oder einen TCP/UDP-Port für Nachrichten von anderen Rechnern), die Destionations, welche das Ziele der Nachrichten sind (z.B. Dateien oder Pipes) und die Filter um Nachrichten z.B. nach Typ oder Priorität zu filtern. Der Befehl log bringt abschließend die drei Bereiche zusammen, wobei die Angabe eines Filters optional ist. Um die eingehenden Nachrichten nach Facilities und Prioritäten zu Ordnen reichen schon folgende Zeilen:

source s_local_all {
  system();
  internal();
  file("/proc/kmsg" program_override("kernel"));
};
destination d_seperateToPriority {
  file ("/var/log/$FACILITY/$FACILITY.$PRIORITY" create_dirs(yes));
};

Hier werden alle lokalen Quellen angezapft und entsprechend nach /var/log/ gespeichert. Oftmals will man aber zusammengehörige Nachrichten unterschiedlicher Priorität nicht aus mehreren Dateien zusammen-grep-en. Um alle Nachrichten einer Facility in einer Datei zu speichern kann man noch folgende Destination einfügen:

destination d_facilities {
  file ("/var/log/$FACILITY/$FACILITY.all" create_dirs(yes));
};

Um eine Source und eine Destination zusammmenzuführen fehlt in dem Beispiel nur noch der log-Aufruf. An diesen übergibt man Sources, Filter und Destinations.

log { source(s_local_all); destination(d_facilities); };
log { source(s_local_all); destination(d_seperateToPriority); };

Es sind natürliche auch andere Aufteilungen der Logs möglich. Welche Makros möglich sind kann in der syslog-ng Dokumentation nachgelesen werden.
Um Lognachrichten an einen zentralen Server zu schicken muss folglich nur eine passende Destination definiert werden. Dazu reicht die Angabe einer IP und eines Ports. Sollen die Nachrichten verschlüsselt versendet werden kann SSL verwendet werden.

destination loghost { tcp("10.10.10.10" port(5140)); };

In der Regel will man aber nicht alle Logs zum zentralen Server schicken. Bei syslog-ng hat jede Nachricht eine von acht Prioritäten. Während des normalen Betriebs sind in der Regeln nur die Stufen emerg, alert, crit, err und warning von Interesse. Es macht also Sinn alle anderen Logs (notice, info, debug) vor dem Senden zum Logserver zu filtern.

filter f_warn2emerg { level(warn .. emerg); };

Der Filter bewirkt, dass nur Nachrichten mit einer Priorität von warn bis emerg berücksichtigt werden. Damit der Filter auch aktiv wird, muss dieser an den log-Aufruf übergeben werden. Hier können auch mehrere Filter hintereinander übergeben werden.

log { source(s_local_all); filter(f_warn2emerg); destination(loghost); };

Somit sendet der Client die Logs an unseren zentralen Server. Dieser muss natürlich noch so konfiguriert werden, dass er die Meldungen annimmt. Dazu reicht eine neue Source am Server aus, die am TCP-Port 5140 lauscht.

source s_remote_tcp { tcp( ip(10.10.10.10) port(5140) ); };

Auf dem Server fehlen jetzt nur noch die Destinations und eventuelle Filter. Diese können analog zum oberen Beispiel definiert werden.
In Normalfall sind Logdateien nicht besonders benutzerfreundlich. Eine Analyse der Logdateien vieler Hosts ist ohne weitere Hilfsmittel nicht zu empfehlen. Eine bessere Möglichkeiten stellen Tools wie Logstash, Graylog2 oder die Icinga EventDB dar. Letztere kann mit Hilfe eines kleines Perl-Skripts gefüttert werden. Dazu muss der Logserver die eingehenden Logs an eine Pipe weiterleiten. Diese gibt man in der Konfigurationsdatei von syslog-ng als Destination an. Zusätzlich wird hier noch die Darstellung der Logs angepasst.

destination d_pipe {
  pipe("/var/run/syslog-ng.pipe",
  template("$HOST\t$SOURCEIP\t$PRI\t$YEAR-$MONTH-$DAY\t$HOUR:$MIN:$SEC\t$PROGRAM\t$MSG\n"));
};

Das Perlskript syslog-ng2mysql.pl überwacht diese Pipe und schickt neue Logs an eine MySQL Datenbank, welche wiederrum die EventDB mit Daten versorgt (weitere Infos).
Jetzt noch die Konfigurationsdateien der Log-Clients mit Hilfe von Puppet verteilen und man ist der Flut der Lognachrichten gewappnet.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Weekly Snap: EventDB v2 out, Puppet Course up & OSDC 2011 sold out

28 March – 1 April turned over the month with a new release of EventDB, a Puppet training course, a sold out OSDC and an Icinga Facebook extension to mark the 1st April day.
Jannis released EventDB version 2.0 with a wealth of new features in performance, scalability and user friendliness. Now in the form of an Icinga cronk for both the new Icinga Web and Classic Web, EventDB has its own database and enables separation in the connections of read and write functions to handle greater loads. In the cronk, events can be filtered freely to be viewed by host, messages or applications etc. making it even more convenient for admins to use. The plugin now also features status tagging of multiple facilities and various levels of severity. To top it off, it too supports IPv6 and IPv4. Download EventDB v2 from netways.org or our git.
From the events team, Rebecca gave us details on the upcoming Puppet training course on 24 -26 May. From configuration and understanding the resource abstraction layer to meta-parameters, dependencies and events, students will leave the course fully prepared to run their own Puppet systems. The course package includes 3 nights accommodation, catering, course materials and a complementary laptop in class. To take advantage of greater automation in your configuration management, register at our training center.
On the topic of registrations, Manuela closed the door on those to the OSDC 2011 which sold out with 100 guests. For those who missed out this year, we hope to see you in 2012 on 25 -26 April.
Finally, no start to April is complete without a good trick – this year with a new extension ‘Social 4 Icinga’, integrating Facebook into Icinga monitoring.

Version 2.0 der EventDB released

Seit heute ist Version 2.0 unserer EventDB released.

Externe Ereignisquellen wie z.B. SNMP-Traps oder Logfiles lassen sich damit in Icinga/Nagios® berücksichtigen und übersichtlich darstellen. Seit der letzten Version haben wir Performance, Skalierbarkeit und Usability stark optimiert.

Ein kleiner Überblick über die wichtigsten Änderungen:
1. Performance
Bei großen Umgebungen litt die EventDB bisher oftmals an Performanceschwäche: Sobald die Eventanzahl in die Millionenzahl ging, stiegen die Wartezeiten bei den Datenbankabfragen ebenfalls stark an. Hier haben wir angesetzt und das Datenbankschema optimiert.
Der Icinga-Web Cronk besitzt jetzt ebenfalls eine dezidierte Datenbank und unterstützt die Möglichkeit, separate Verbindungen für Lese- und Schreiboperationen zu verwenden.
Dadurch skaliert die EventDB jetzt deutlich besser, Abfragen gehen auch bei großen Datenmengen zügig vonstatten.
2. Icinga-Cronk und Classic Web
Übersicht über die EventDB
Der Icinga-Web Cronk wurde mit Augenmerk auf die Usability und Übersichtlichkeit umgeschrieben. Dreh- und Angelpunkt des neuen Interfaces ist dabei die neue Suchmaske: Mit ihr können Events einfach nach den verschiedensten Kriterien gefiltert werden. Egal ob man einfach nur gewisse Quellen ausblenden will oder komplexe Suchen nach verschiedenen Hosts, Messages, Programmen, etc. einrichten will – für jedes Szenario kann ein Filter eingerichtet werden.
Soll es mal schneller gehen bietet die Eventübersicht mit den praktischen Quickfiltern die Möglichkeit, schnell nach Hostnamen (oder Adressen) zu filtern oder bestimmte Eventkategorien auszublenden. Die Integration im Icinga-Web ist dabei nahtlos, Cronks können gespeichert, in Portalen zusammengefasst werden, etc.
Wer das klassische Interface bevorzugt, kann dieses natürlich auch weiterhin nutzen. Zwar hat sich im Featureset nichts geändert, dank der verbesserten Performance lohnt sich ein Umstieg jedoch trotzdem.
3. Plugin und IPv6
Beim Plugin gibt es neben einer neuen Option zur Integration ins Icinga-Web jetzt auch die Möglichkeit, mehrere Facilities und Severities gleichzeitig mit einem Status zu taggen. Ausserdem unterstützt die EventDB jetzt auch Hostadressen im IPv6 und IPv4 Format.
Die neue Version findet man wie immer unter netways.org oder direkt im git.

Kempten im Winter

WinterwaldSchon seit mehreren Jahren reisen wir, immer im Winter, nach Kempten um dort im Nagios Umfeld zu helfen. Der Weg ins Allgäu ist immer wieder malerisch schön und Kempten im Winter ist auf jeden Fall eine Reise wert. Mal sehen ob es mir irgendwann gelingt den Ort im Frühling oder Sommer zu sehen.
Nachdem wir dies mal unter anderem die Anbindung von SNMP Traps via snmpd und snmptt an die EventDB erledigt haben, rückt vielleicht beim nächsten mal Icinga in den Fokus.

Nagios on Solaris

sun-logoDie Installation von Nagios auf kommerziellen Unix-System stellt uns gelegentlich vor Herausforderungen. Gerade bei Solaris hat sich die Installierbarkeit in den letzten Monaten deutlich verbessert. Für mich relativieren sich diese Meinungen aus verschiedenen Foren ein wenig, seitdem ich bei unserem Partner SUN für einen ihrer RZ Hosting Kunden ein SNMP Trap Monitoring eingerichtet habe.
Hierzu wurde Nagios, snmptt und die NETWAYS EventDB auf Solaris 10 installiert. Nachdem alle nötigen Softwareabhängigkeiten aus dem SUN Freeware Repository installiert wurden, ging die Installation einfach und ohne größere Fehler von der Hand. Es musste lediglich ein einziges mal ein Pfad zum Kompiler umgebogen werden.
Auch wenn die Installation von grafischen Nagios Addons wie z. B. den NagiosGrapher oder NagVis noch etwas Probleme mit Solaris bereiten, ist dies doch schon einmal ein Lichtblick am Betriebssystem-Horizont.

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.

Ask the developer: EventDB for Nagios

This entry is part 4 of 5 in the series Ask the developer


What is EventDB?
EventDB is an event handler for Nagios which filters traps and logs. It extends on standard Nagios monitoring to check traps and logs for errors from software components and network devices.

How does it work?
Software such as Linux or Windows generate log files and other events that are not machine parsable. EventDB consists of a web interface, a Nagios plugin and a MySQL database, where the events are sent to via adapters such as syslog, SNMP Trap or MS event log.

Then check_eventdb reads these events and reports errors (as specified in configuration) to Nagios. Via the EventDB front end, administrators can acknowledge the events which check_eventdb no longer needs to recognize or report to Nagios in the future.
What do you get in the download?
You get a set of scripts used to store SNMP/syslog/other event based information in a MySQL database. This EventDB package consists of:
* MySQL database structure
* EventDB web front end
* Nagios plugin
* Syslog-ng configuration snippets
How does it compare to other event loggers?
There are similar programs such as Tivoli and OpenView, but these are licensed and relatively expensive. From what I know, it is the only event handler for Nagios which can handle these types of events, work with syslog and MS event logs.
As a developer, what do you love about EventDB?
The fact that it’s so simple. It’s essentially a text filter based on a MySQL database.
EventDB’s simplicity allows it to be practically invulnerable to errors, and being based on such a reliable interface like MySQL, EventDB remains reliably robust.
EventDB in a nutshell?
EventDB is for administrators who require more detailed monitoring than what Nagios offers out of the box.
Monitoring software components is complex but necessary- especially for large environments.
Here an administrator need not write their own checks, they can simply download a pre-packaged event handler for free. It doesn’t get better than that.
More information:
Features & how EventDB works

Join the project or download