So mittlerweile bin ich wieder zu Hause und erholt von zwei interessanten Tagen in Nürnberg auf der OSMC 2011. Ganz besondere Grüße an dieser Stelle gehen an die anderen aussässigen Sprecher: Reinhard Scheck mit Cacti, Remo Rickli mit NeDI, Dr. Michael Schwartzkopff mit SNMPv3, Georg Kostner mit Syslog, Roland Huß mit Jolokai und Sebastian Harl mit collectd. Vielen Dank dass ihr das doch recht Icinga und Nagios lastige Programm aufgelockert habt. Von 23 Vorträgen inklusive der Begrüssung gab es 7 Vorträge die nichts mit Nagios oder einem Nagios-Fork zu tun hatten ;) Die Highlights für mich auf der Programmliste waren:
Ich hatte schon einmal das Vergnügen in Forschungsprojekten mitzuarbeiten. Dabei ging es auch um die Leistungsfähigkeit von Open-Source Monitoringanwendungen. Daher habe ich mich auf den Performance-Vergleich von Nagios, Icinga und Shinken besonders gefreut. Zudem war ich gespannt wie sich die beiden Forks Shinken und Icinga auf die Leistungsfähigkeit auswirken. Einer der Hauptkritikpunkte der beiden Forks war ja schliesslich, dass im Nagios Core nur schwer oder keine Veränderungen gemacht werden konnten. Es hat mich und vermutlich wie auch viele andere brennend interessiert ob sich die zwei Jahre fork() positiv auf Shinken und den Icinga Core ausgewirkt haben.
Beim Test der Scheduler in Nagios und Icinga waren "leider" keine Unterschiede festzustellen. Es wurde eine Simulation mit bis zu 60.000 "Checks" und zufällig schwankenden Ausführzeiten beschrieben. Der Code der Scheduler wurde in der Ausarbeitung nicht betrachtet. Nagios als auch Icinga zeigten bei der Präsentation ein ähnliches nahezu "gleiches" Verhalten. Shinken hat eine lose gekoppelte Architektur im Kern und zeigte eine wesentlich besseres Verhalten. Damit das ganze für alle drei Tools noch vergleichbar bleibt wurde der Performancevergleich dann mit Nagios + mod_gearman und Icinga + mod_gearman weitergeführt. "Gearman" ist eine eigenständiges Open Source Projekt und stellt eine API bereit um Anwendungen zu verteilen – "Nagios/Icinga-on-Steroids".
Das Ergebnis war wenig verwunderlich, Nagios/Icinga hatten das gleiche Verhalten und waren am Ende, was die Latenz-Zeiten angeht, einen Tick besser als Shinken. Vermutlich ist hier tatsächlich ein kleiner Vorteil der C-Implementierung des Nagios-Core gegenüber Python zu sehen – but who knows. Das Ergebnis, dass die Check-Latenz über der Zeit linear ansteigt würde ich mit einfachen Vermutungen bezweifeln. Die Beschreibung der Skalierbarkeit der Scheduler mit der "Check-Latenz" über der Zeit mit der "Big-O Notation" zu beschreiben halte ich persönlich für gewagt. Laut meinem Verständnis sagt mir die O-Notation in der Informatik etwas über die Effizienz von Algorithmen aus, der Code der Scheduler wurde dabei ja bewusst NICHT analysiert – ich lasse mich aber an dieser Stelle gerne eines besseren belehren. Das fork() aufwändiger ist als Thread spawn oder gar Thread Pools ist eigentlich klar – von daher war ich ein wenig enttäuscht, kritische Objektivität hätte ich mir gewünscht. Ich bin wohl zu viele Barcamps und freie Konferenzen im c4fd Umfeld gewohnt ;)
Der einzige fork() der den Kern von Nagios überarbeitet hat ist meiner Ansicht nach Shinken. Sie haben durch eine komplette Reimplementierung in Python Schwächen bei der Skalierung durch eine andere Architektur angepeilt. Das ganze wurde damit für mich eigentlich erst auf den zweiten Blick deutlich. Was den Inhalt angeht, waren vermutlich meine persönlichen Erwartungen etwas zu hoch, da ich mich mit diesem Thema schon beschäftigt habe.
Bei dem Vortrag "Monitoring at large" wurde dargestellt welche Ideen im Icinga Projekt stecken um das Thema Verteilbarkeit und Skalierbarkeit besser zu adressieren. Vorallem das Thema Queuing mit ZeroMQ scheint einiges an Potential zu verbergen. Im Thema SLA Reporting ging es letztendlich darum wie man die Daten aus einem Icinga Availability Report "parst" und in MySQL und JasperReports auswertet. Ich dachte ich kann mir da an der Stelle etwas abgucken was ich OpenNMS verwenden kann, da war aber nix für mich dabei :) Den Vortrag zu Collectd war sehr interessant und wirklich ausführlich dargestellt. Da in OpenNMS eine ähnliche Implementierung der Datacollection hat, sind die Problemdomänen hier identisch. Jörg Linge hat zudem seinen erfolgreichen "Grapher" PNP4Nagios vorgestellt. So wie ich es verstanden habe, hat der wohl bis jetzt schon so einige Remake Versuche überlebt. Kleiner Tipp, das Projekte einfach in PNP4${fork} umbenennen, dann wird es vermutlich einfacher ;)
Mit Jolokia hat sich noch ein weiteres Projekt vorgestellt, welches sich dem interessanten Thema Java Monitoring annimmt. In dem Vortrag wurde kurz vorgestellt welche Probleme mit JSR-160 und JMX im Monitoring-Umfeld auftreten können. Jolokia schafft hier Abhilfe und stellt einen "einfach" erreichbaren JMX Proxy in die JVM. Das ganze ist unabhängig von der eingesetzten Monitoring-Lösung und damit auf jeden fall einen Blick wert, für alle die sich wie ich in J-Land aufhalten.
Ansonsten kann man grob zusammengefasst sagen, dass das Thema in Richtung mehr "Checks", mehr "Services" geht und wie man das mit Steroiden wie Gearman und ZeroMQ, erreichen kann. Um die CIO`s Happy zu machen ist gerade JasperReports der "Heiße Scheiß". Kann ich ja in einer gewissen Weise auch gut verstehen :) Für mich ist auf jeden Fall Shinken, NeDi und Collectd weiter unter Beobachtung. Icinga gibt mit InGraph ziemlich Vollgas was die Web UI angeht. Das Thema Skalierbarkeit ist meines erachtens momentan mit einem haufen Ideen in der Findungsphase. Bei dem Thema SLA-Reporting bin ich wohl erstmal auf mich alleine gestellt ;) Allen in allem war es eine wirklich angenehme und entspannte Atmosphäre. Die Organisation war absolut perfekt. Man merkt, dass das NETWAYS Team gut eingespielt ist. Ich bedanke mich bei den Organisatoren für die gelungene Konferenz, den regen Erfahrungsaustausch und dass ich die Gelegenheit hatte viele Menschen mit einem Vortrag zu OpenNMS zu quälen ;)
So Long, and Thanks for All the Fish
Links zum Thema:
