Die ersten Webinare sind vorbei und die nächsten folgen zugleich!

Die ersten beiden Webinare zum Thema Puppet: Aufbau einer Puppet Enterprise Umgebung und Icinga Web: Arbeiten mit Icinga Web sind nun abgeschlossen. Die Videos können natürlich wie immer über unser Webinar-Archiv eingesehen werden.

Die Termine für die nächsten Webinare sind natürlich auch schon geplant:

Titel Zeitraum
RequestTracker: Open Source Ticket System 29. April 2014 – 10:30 Uhr
Puppet: Aufbau einer Open Source Umgebung 09. Mai 2014 – 10:30 Uhr
Puppet: Provisionierung von VMware 28. Mai 2014 – 10:30 Uhr
Bareos: Open Source Backup leicht gemacht 10. Juni 2014 – 10:30 Uhr
inGraph: Neues Webfrontend für Graphite 26. Juni 2014 – 10:30 Uhr

Wer sich für ein oder alle Webinare interessiert, sollte sich schnell registrieren bevor alle Plätze vergeben sind. Am 29. April 2014 um 10:30 Uhr starten wir bereits wieder mit dem Thema RequestTracker: Open Source Ticket System

Übrigens: Neben unserem Webinar-Archiv haben wir auch einen eigenen YouTube-Channel, der sehr gut als Vorbereitung für die Open Source Data Center Conference geeignet ist!

Bis dahin!

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

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

(more…)

Jannis Mosshammer

Autor: Jannis Mosshammer

Nachdem Jannis als Softwareentwickler in Vollzeit bei NETWAYS angefangen hat, studiert er aktuell Informatik und arbeitet weiter als Werkstudent bei uns. Er ist erstklassiger Gitarrist und vermutlich mit Santana in 23 Generation verwandt. Hauptsächlich arbeitet er bei uns an Icinga Web, LConf oder der EventDB.

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

Autor: Markus Frosch

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 Ledermueller

Autor: Achim Ledermueller

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.

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.

Jannis Mosshammer

Autor: Jannis Mosshammer

Nachdem Jannis als Softwareentwickler in Vollzeit bei NETWAYS angefangen hat, studiert er aktuell Informatik und arbeitet weiter als Werkstudent bei uns. Er ist erstklassiger Gitarrist und vermutlich mit Santana in 23 Generation verwandt. Hauptsächlich arbeitet er bei uns an Icinga Web, LConf oder der EventDB.

Syslog-NG 3.2 bringt viele neue Funktionen

Vor ein paar Tagen ist die neue Version 3.2.1 von Systlog-NG erschienen. Laut Website des Herstellers Balabit bietet die neue Version die längste Liste an Neuigkeiten in der Geschichte des Projekts. Wichtigste Neuerungen sind beispielsweise Logfile Korrelierung und ein neues Plugin System. Weiterhin können Daten zum Prozess Accounting gesammelt werden und es werden Trigger unterstützt, die dann Aktionen auslösen können.

Syslog-NG allgemein ermöglicht sicheres Logging, die Protokolle IPv4 und IPv6 sowie die Möglichkeit Log-Nachrichten zu filtern oder sogar umzuschreiben. Neben der Open-Source-Version bietet Hersteller Balabit auch eine kostenpflichtige Variante, die etwas mehr Features bietet, beispielsweise der verschlüsselte und revisionssichere Speicherung von Log-Daten.

Balázs Scheidler, der CEO vom Hersteller Balabit IT Security, war schon 2009 als Referent auf der OSDC und hat damals die neuen Möglichkeiten von Syslog-NG 3.0 vorgestellt.

Julian Hein

Autor: Julian Hein

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.