NETWAYS Webinar Kalender Update

netwaysAuch wenn mein letzter Blog-Post bzgl. unserer Webinare schon eine ganze weile her ist, erweitern wir natürlich regelmäßig unseren Kalender um diverse Themen. Neu hinzugekommen ist jetzt ein weiteres Logstash Webinar am 11. November 2014 um 10:30 Uhr, wobei es inhaltlich diesmal schwerpunktmäßig um die Integration von Windows und Linux Logmeldungen geht und eine spätere Auswertung über das Webfrontend.
Darüber hinhaus möchte ich gleich die Gelegenheit nutzen um alle die sich noch nicht angemeldet haben auf die nächsten Icinga 2 Webinare hinzuweisen. Diese Woche am 25. September um 10:30 Uhr zeigen Markus und ich wie Icinga 2 und Graphite optimal zusammenarbeiten können.
Wer sich zusätzlich für das Cluster-Feature von Icinga 2 interessiert, ist für das zugehörige Webinar zur integrierten Hochverfügbarkeit am 07. Oktober 2014 um 14:00 Uhr natürlich gerne eingeladen.
Um den Überblick nicht zu verlieren, gibt es noch einmal eine kurze Übersicht (natürlich auch auf unserer Webinar-Seite zu finden):

Titel Zeitraum
Icinga 2: Integration von Graphite 25. September 2014 – 10:30 Uhr
Icinga 2: Integrierte Hochverfügbarkeit 07. Oktober 2014 – 14:00 Uhr
Logstash: Windows und Linux Log Management 11. November 2014 – 10:30 Uhr

Wie immer freuen wir uns auf eine rege Teilnahme!

Christian Stein
Christian Stein
Lead Senior Account Manager

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".

Reminder für das morgige Logstash-Webinar

logstash_01 Ich möchte noch einmal alle Logfile-Archivierer (und natürlich jene die es werden wollen) auf das morgige Logstash Webinar hinweisen. Unser Ziel wird es sein, die Architektur und Funktionsweise zu vermitteln. Dabei wird ein großer Schwerpunkt auf unserer Live-Demo liegen, in der wir Kibana, Elastic-Search und sogar einige Konfigurationen anschauen werden.
Starten wird das Webinar morgen Früh um 10:30 Uhr.
Wer sich vorab einige andere Webinare ansehen will, dem sei einerseits unser Webinar-Archiv nahelegt oder gleich unser erstes Logstash Webinar.
Wer bereits für die Zukunft planen möchte, kann sich ebenfalls für die beiden nächsten geplanten Webinare registrieren:

Icinga Web 2 Icinga Web in neuem Design
25. Februar 2014 – 10:30 Uh
Icinga 2 Entwicklungsstand 2014
05. März 2014 – 10:30 Uhr

Wie immer werden wir das Video und die Präsentation schnellstmöglich in unserem Webinar-Archiv online zur Verfügung stellen.
Cebit BlogWer eine persönliche Beratung zu Logstash wünscht, kann sich entweder über unser Kontaktformular bei uns melden oder uns auf der CeBIT im Open Source Park, Halle 6, an Stand E16 (310) besuchen. Um uns schneller zu finden, gibt es natürlich auch eine Wegbeschreibung.
Bis morgen im Webinar!

Christian Stein
Christian Stein
Lead Senior Account Manager

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".

Weekly Snap: Syslog & Graphite, Dashing & Brainstorming

weekly snap27 – 31 January finished off the month with events aplenty, monitoring in different forms and best practices in brainstorming and virtual machines.
In usual style, Eva started the week counting 71 days to the OSDC by sharing Philipp Reisner’s talk on the latest in DRBD9. She went on to announce our Call for Papers for the next Puppet Camp in Berlin on 11 April.
Seeking out best practices, Marius H considered the best way to brainstorm as Dirk compared Cloud Provisioner to Compute Resource to find the best method to deploy virtual machines.
Thomas then added a second instalment to his Logstash series with a look at the Logstash predecessor Syslog and Bernd shared a video on the reality of conference calling.
The week ended on monitoring, as Marius G took a look at Dashing for good-looking, custom dashboards and Markus W introduced our advanced course on Real-time Graphing with Graphite.

Der Klassiker: syslog -> logstash

Bevor es an den Aufbau neuer Features mit logstash geht, soll erst mal der übliche Vorläufer von logstash in Netzwerken ersetzt werden: Der gute alte Syslog Server.
Zu Syslog finden sich weiterführende Informationen in der Wikipedia, deshalb hier nur kurz umrissen: Syslog ist sowohl ein Protokoll, als auch der Name eines Tools, das dieses Protokoll benutzt, um Logs innerhalb eines Systems von Applikationen einzusammeln und in Logfiles zu schreiben und sie auch übers Netzwerk an andere Hosts zu schicken. Diese anderen Hosts sind normalerweise die eingangs erwähnten Syslog Server, die einfach mal alles an Logs sammeln, was ihnen präsentiert wird und in lokale Logfiles schreiben.logstash_01
Gegenüber Lösungen wie logstash ergeben sich bei Syslog vor allem 3 Probleme:

  1. Die Lösung skaliert nicht. Wenn ein Server nicht mehr mit dem Annehmen und Wegschreiben von Logs mitkommt, kann man ihn höchstens durch stärkere Hardware ersetzen. Irgendwann ist da aber Schluss.
  2. Die Logs liegen genau so am Syslog Server wie auf stand-alone Hosts auch. Also unstrukturiert. Durchsuchen und Auswerten verlangt normalerweise einiges an grep/awk oder Perl und Regex magic.
  3. Die Übertragung passiert normalerweise unverschlüsselt über UDP. Beides will man normalerweise nicht für kritische Logs. (Auch wenn Ableger wie rsyslog und syslog-ng da teilweise Abhilfe schaffen)

Punkt 1 und 2 kriegt man mit logstash sehr einfach in den Griff. Man kann mit logstash einen Syslog Server bauen, der Logs sowohl im klassischen Syslog Format vom syslog Tool, als auch von neueren Tools wie rsyslog, die auch über TCP und teilweise sogar verschlüsselt senden können, annehmen kann.

input {
  syslog {
    type => "syslog"
    port => 514
  }
}

Aus. Das war’s. Mehr ist nicht nötig und das ist sogar schon etwas mehr, als nötig ist. Der Port ist auch ohne Angabe auf dem Syslog Standard von 514, allerdings sowohl TCP, als auch UDP. Der type ist übrigens frei wählbar und wird nur später benutzt, um den Weg der Nachricht durch logstash zu planen. Er hat nichts damit zu tun, dass Daten im Syslog Format erwartet werden. Weitere Informationen zu den möglichen Optionen des Syslog Input gibt’s in der logstash Dokumentation.
Nochmal zusammengefasst reicht es, dem Quickstart aus dem ersten Beitrag dieser Serie zu folgen und den syslog Teil des obigen Beispiels zum input hinzuzufügen. Jetzt noch die IP Adresse des bisherigen Syslog Servers auf den logstash Server verschieben und fertig.
Zugegeben, natürlich war das Quickstart Beispiel nicht für eine Produktivumgebung gedacht. Dazu fehlt zumindest noch Ausfallsicherheit und die Meldungen werden immer noch ziemlich unstrukturiert abgelegt. Die zum Aufbereiten nötigen Filter können aber ebenso nach und nach hinzugefügt werden. Ziel dieses Artikels war ja, den Syslog Server zu ersetzen und auf weitere Verbesserungen vorzubereiten.
Was mehr Aufwand benötigt ist die gesicherte Übertragung der Syslog Nachrichten an den logstash Server. Mit syslog ist das sowieso nicht möglich. Mit rsyslog Sind aber auf jeden Fall Änderungen an der Konfiguration jedes sendenden Host nötig.
Wer das Beispiel einfach mal ausprobieren möchte und bisher keinen zentralen Syslog Server hatte, kann mit folgenden kurzen Codebeispielen andere Server zum Versand bringen.
syslog:

*.* @192.168.200.2

Wobei 192.168.200.2 hier die IP Adresse des logstash Servers ist. Der Eintrag ist eine Zeile aus /etc/syslog.conf auf den meisten Systemen. Danach muss syslog neu gestartet werden. Mit service syslog restart auf gängigen Linux Distributionen, sofern sie überhaupt noch syslog einsetzen und mit svcadm disable system-log ; svcadm enable system-log auf Solaris.
rsyslog:

*.* @@192.168.200.2:514

Wobei die doppelten @ dafür sorgen, dass die Übertragung über TCP stattfindet. Diese Zeile kann in eine eigene Datei in /etc/rsyslog.d gelegt werden.schulung_logstash
Es soll natürlich hier nicht verheimlicht werden, dass logstash auch eigene Möglichkeiten mitbringt, die Daten auf dem Host einzusammeln und an einen zentralen logstash Server zu schicken. Wie das geht, ist Inhalt eines späteren Artikels oder unserer logstash Schulungen.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

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.

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.

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
Julian Hein
Executive Chairman

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.

OSMC – Motivierter Start in den zweiten Tag

Trotz der Anstrengungen am gestrigen Abend, haben sich heute morgen fast alle Teilnehmer pünktlich um 9.00 Uhr in den Vortragsräumen eingefunden. Auch der zweite Konferenztag hat mit spannenden Vorträgen begonnen.
Merlin – status quo
Den zweiten Tag eröffnete kein Geringerer als Wolfgang Barth mit einem Vortrag über Merlin. Wolfgang erläuterte sehr gut und detailliert die Funktionsweise von Merlin und berichtete über die geplanten Releases. So auch die für Ende Oktober vorgesehene Stable Version 0.9, die verteiltes Monitoring und Synchronisation von Konfigurationen unterstützen wird.
Munin and Nagios
Munin ist ein Tool welches Monitoring und Graphing verbindet. Auftretende Events können an Nagios per NSCA gesendet werden. Ein entsprechender Eventhandler ist integriert. Stig Sandbeck Mathisen zeigte wie Plugins aussehen, welche Möglichkeiten beim Graphing bestehen (z.B. Multigrphen). Mit der kommenden Version 2.0 sind Features möglich wie Zooming der Graphen, nativer SSH Transport von den Nodes zum Master.
Logverarbeitung mit syslog-ng – Status und Zukunft
Syslog-ng ist mittlerweile State of the Art im zentralen Logging. Martin Grauel stellte die Struktur des Systems dar und zeigte, wie man das Logging optimieren kann. Z.B. die Strukturierung der Messagetexte mit dem patterndb-Framework welches in Zukunft sogar Event Correlation ermöglicht.
Mit Hilfe des Frameworks können Texte in Name Value Paare aufgeteilt werden, die dann in einer nachgelagerten Datenbankverarbeitung natürlich wesentlich schneller und ressourcensparender für Auswertungen zur Verfügung stehen.
BalaBit stellt als Communityprojekt eine Patterndatenbank zur Verfügung, in der schon Pattern zu finden sind und auch von anderen Anwendern hochgeladen werden können.
Puppet als Bindeglied zum Monitoring
Kurz vor der Mittagspause war Birger Schmidt an der Reihe. Birger lieferte in “Puppet als Bindeglied zum Monitoring” Informationen an Hintergründen und Basics zu Puppet. Weiter erläuterte er die Einsatzmöglichkeiten des Tools im Bereich Nagios/Icinga und veranschaulichte dies anhand praktischer Beispiele zur Konfigurationsverteilung.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Live vom Nordic Meet on Nagios: syslog-ng

Bereits gestern referierte Balazs Scheidler, Erfinder von syslog-ng, über den aktuellen Stand seines Projekts. Der Vortrag über die Verbesserungen und Erweiterungen von syslog-ng 3.0, war für uns größtenteils bekannt, da Balazs erst im April auf unserer OSDC zu Gast war und dort in einem Vortrag auf diese Themen eingegangen ist.
Etwas stärker wurde jedoch auf die Implementation von Parsern eingegangen, welches die Definition verschiedener Formatinterpreter zur Mustererkennung in Logfiles ermöglicht. Eine für mich neue Idee, war die Verarbeitung von Nagios check-results mit Hilfe dieser Parser und anschließende Weiterverarbeitung über das Nagios commandfile. Die Idee ist auf jeden Fall einen Versuch in einem unserer nächsten Consulting-Workshops wert.
In den nächsten Versionen soll syslog-ng verstärkt in Richtung Interpretation der Inhalte gehen und sich nicht mehr allein auf den Transport und Konsolidierung der Logfiles beschränken.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Live von der OSDC: syslog-ng 3.0

img_00021 Der Erfinder von syslog-ng und  CEO der von ihm gegründeten Firma Balabit, Balazs Scheidler,  referierte gerade über die neuen Möglichkeiten von syslog-ng 3.0
Als freie Syslog-Alternative hat syslog-ng in den letzten Jahren eine große Fangemeinde gewinnen können und ist in vielen Linux Distributionen zum Standard Syslog geworden. Mit der neue Version erweitert syslog-ng die klassische Aufgabenstellung der Transportschicht und bietet vielfältige Möglichkeiten Loginhalte zu parsen und weiterzuverarbeiten.
Besonders spannend hierbei sind die DB-Parser, welche Logfiles nach Filterung direkt in die Datenbank speichern können und somit die Weiterverarbeitung erleichtern. Mit unserer EventDB haben wir in vielen vergangenen Projekten genau diese Möglichkeit der Weiterverarbeitung genutzt und können mit syslog-ng 3.0 viele Aufgaben an den syslogger delegieren.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.