Das ist mein Blog.

Hier gibts, was ich tue, getan habe und vielleicht tun werde. Auch, wenn und weil das total unwichtig für den weiteren Verlauf der Geschichte ist. Viel Spaß damit.

Wer mich möglichst zeitnah erreichen und/oder beschimpfen will, versuche dies per Email (s.u.), per Twitter, auf Facebook oder im ircnet oder suche mich persönlich auf.

TMG §5 Kontaktdaten.

RSS-Feed Startseite

Einträge nach Kategorien

Einträge nach Datum

RSS-Feed
Startseite

30.10.2009

17:12 Uhr  OSMC - Öberwachong öber all!

Und ich meine diesmal nicht Kameras und Schleierrasterfahndung, sondern die Beobachtung von Netzen, Rechnern und darauf laufenden Diensten auf Funktion - ein (leider) wichtiger Teil meines Jobs.

Gestern und vorgestern gab es dazu eine Konferenz in Nürnberg, die Open Source Monitoring Conference. Dort bin ich mit einem zappeligen Kollegen hingefahren, auf dem Fußweg vom Bahnhof zum Hotel sind wir dann auch erstmal direkt durchs Rotlichtviertel gestolpert - im Hotel gabs dann lecker Abendessen und es war ziemlich voll - eine trotz Wirtschaftsdepression ausgebuchte Konferenz, schon mal nicht schlecht.

Nun aber eher zum Inhalt, und was ich mitgenommen habe.

Leider gibt es die meisten Folien noch nicht online, ich erweitere diesen Artikel entsprechend, wenn die Folien verfügbar sind.

Jetzt wirds technisch, nicht computeraffine Leser können also aufhören, es verstehen zu wollen oder gleich aufhören, es zu lesen.

Ich schreib auch noch am Wochenende was neues, ich hab nämlich ein neues Spielzeug bekommen.

Der international agierende Großheilige St. Isotopp eröffnete den einen Track (es gab zwei parallele) mit einem Vortrag zum Thema Monitoring MySQL (was sich dann gleichzeitig als MySQL-Tuning-Vortrag herausgestellt hat).

Kristian hat seinen Vortrag mit einer (für mich) Banalität eröffnet, und zwar mit der Feststellung, daß es unterschiedliche Gründe für 'Monitoring' gibt, und das meist jeder, den man fragt, was anderes darunter versteht. Und zwar mindestens

• Operations (also Fehlererkennung und Handling),
• Infrastruktur-Entwicklung (Sizing, zukünftige Entwicklungen abschätzen),
• Entwicklung (Fehler in Software erkennen und in zukünftigen Versionen ausbauen, neue Features kontrollieren),
• Verfügbarkeitsauswertung (SLA Compliance).

Jede dieser Monitoringarten hat unterschiedliche Anforderungen in Bezug auf Zweck, Messtechnik, abzulieferndes Ergebnis, mögliche Latenz und Verfügbarkeit - aus diesem Grunde solle man es eher vermeiden, die Daten für alle Monitoring-Typen gemeinsam zu erheben oder zu verarbeiten.
Das ist für mich banal, weil wir das sowieso so handhaben - wir erfassen mit unserem Operations-Monitoring (zum Vergleich: Wir setzen Nagios zur Überwachung von etwa 550 Hosts und 2400 Services ein) keine Performancedaten, sondern machen dies z.B. mit Munin. Natürlich erfasst unser Nagios auch Performancedaten (das machen viele Checks automatisch), aber wir werten diese nicht via Nagios aus.

Mir war nicht klar, daß andere das in extremer Weise tun, das stellte sich erst im Laufe der Konferenz heraus. Genauso war mir nicht klar, daß es sinnvoller ist, das bewußt zu trennen (wir machen das wohl auch, weil es bei der Einführung von Nagios (damals noch Netsaint) noch nicht vorgesehen war). Wenn man mittels Nagios auch Daten für die Performanceauswertung erfassen will, muß man natürlich auch entsprechende Checks einrichten, die dann dem Operating aber auch nicht mehr Informationen zur Fehlerbeseitigung liefern als die eh schon vorhanden Checks, dafür aber auf dem Nagiossystem ordentlich Last und vor allem gewaltige Datenmengen erzeugen.

Dieses für mich 'Nichtproblem' zog sich durch die ganze Konferenz, meist verbunden mit dem Wunsch, dem Webinterface von Nagios mehr Konfigurationsmöglichkeiten, Views und Personalisierung zu verpassen - was mir total wumpe ist. Das Webinterface von Nagios ist häßlich, aber es erfüllt seinen Zweck. Etwas, das mich nachts um 3:48 Uhr weckt, muß nicht schön sein, sondern ich muß erkennen können, was Phase ist und ich muß das Gebimmel zielgerichtet abschalten können. Das lösen wir durch sinnvolle Checks und Abhängigkeiten und nicht durch Web2.0-Grafik. Das sieht natürlich anders aus, wenn man schöne Grafiken über z.B. die Auslastung von Mailqueues direkt im gleichen Tool haben will.

Ebenso scheinen viele aus dem Grund der Weiterverwurstung von fürs Operating erzeugten Daten die Datenbankschnittstelle von Nagios zu verwenden - und dort alles hineinzuballern, was man zumindest fürs Operating nach drei Tagen gar nicht mehr braucht. Ein ähnliches Problem scheint es auch beim (kommerziellen) MySQL-Enterprisemanager zu geben, dies hat bei Kristian (als Ex-MySQLler) dazu geführt, noch während der Konferenz in das NDO-Schema hineinzukriechen und ein paar Ideen dazu zu veröffentlichen. Ich hoffe, das lesen mal die richtigen, z.B. die Jungs vom Icinga-Team.

Der Rest von Kristians Vortrag taugt dafür, ein Gefühl dafür zu bekommen, welche Parameter man für ein Operating-Monitoring gerne überwachen möchte und MySQL zu tunen, also grundsätzliche Performanceprobleme zu verstehen und dem Datnbanksystem dann auf die Sprünge zu helfen. Guckt Euch die Folien an, es ist für mich als Nicht-DBA ne Menge Stoff dabei, von dem man zumindest mal gehört haben sollte.

Als nächstes habe ich einen Vortrag über SNMP gehört (net-snmp: The forgotten classic) - allerdings hat das bei mir nicht so richtig gezündet, weil es um wirklich classic snmp generell ging und nicht so sehr eine sinnvolle Nagiosintegration. Ich finde SNMP zum Glück meist vermeidbar, und vorallem sollte man das meiner Meinung auch immer tun, wenn das zu monitorende Gerät die Möglichkeit bietet, anders an Informationen zu kommen. Inzwischen ist das bis auf bei wenigen Switchen und ähnlicher Hardware problemlos möglich.

Im Anschluß gab es einen Vortrag zu einer Migration von Tivoli auf Nagios in einer wirklich großen (>11.000 Hosts) und heterogenen Umgebung (bei Audi).

Interessant zu sehen, welche Prozeduren dort eine Rolle spielen, aber vorallem hat mir der lakonische, stark dialektgefärbte Sprachstil von Eric Pfaller gut gefallen.

Nicht verstehen kann ich allerdings, wieso man dort statt nrpe (damit kann man Testkommandos auf Remotesystemen absetzen) check_ssh einsetzt - der ssh-Verbindungsaufbau ist verschlüsselungstechnisch um Größenordnungen teurer als der von nrpe. Scheinbar haben die das auch schon bemerkt, deswegen wird mit selbstgefrickelten Cachingmechanismen gearbeitet (anscheindend werden mehrere Checkanfragen und deren Antworten gesammelt und dann gemeinsam übertragen - ... Latenzen...).

Daneben verwendet Audi zur Verwaltung und Erzeugnung der Nagioskonfiguration einen LDAP-Server, der die entsprechenden Templates vorhält. Das hat allerdings einen sinnvollen aber ebenso perversen Touch und ist damit interessant :-)

Audi öffnet übrigens automatisiert für jeden hard-status CRITICAL nen Ticket. Toller Spaß.

Allerdings fand ich die Ankündigung zum Vortrag Application monitoring - Bridging the gap, der parallel zur Vorstellung des LDAPs als Backend für die Objektkonfiguration laufen sollte, interessanter, so daß ich dann doch dahin gegangen bin - ich war auch nicht enttäuscht.

Michael Medin, der in seiner not-so-spare time für Oracle arbeitet, ist ein guter Redner und inhaltlich ging es am Beispiel der jmx-console um Anwendungsmonitoring. Wir setzen jmx-monitoring ein, allerdings nicht im Operating, sondern zum Debugging, Development und allgemeinen Beobachten von Java-Anwendungen.

Medins Kernforderung: Redet miteinander, redet mit den Entwicklern! Stellt den Entwicklern Möglichkeiten zur Beobachtung ihrer Anwendungen zur Verfügung, in der Regel wissen diese nämlich weder, wie sich Ihre Anwendungen unter dem Eindruck von echten Benutzern verhalten, noch, daß es diese (feine) Möglichkeit bei Java-VMs, .NET und anderen Sprachen gibt. Gerade, wenn wie bei Java eine komplette VM hochgerissen wird, ist es sehr interesaant zu sehen, wie die garbage collection (nicht) funktioniert, wie viele Sessions der Datenbankconnector hält und was sich so im Heapspace tummelt.

Dabei ist noch das für mich neue jmx4perl aufgetaucht, daß anders als unsere Lösung keine java-libs zieht und damit auch keine eigene java-vm bootet.

Als letzten Vortrag am Mittwoch habe ich mir die Präse vom Icinga-Team gegeben. Icinga ist ein Nagios-Fork (Gründe für den Fork), die Core Teammitglieder sind anscheinend alle aus der Gegend und im Dunstkreis des Veranstalters Netways angesiedelt. Der Vortrag war von der Darbietung her erfrischend unprofessionell (aber nicht vom Inhalt) - durch den ständig wechelnden Vortragenden (und den Kampf darum) wurde es nicht langweilig.

Auch hier ging es (wie in den von mir eher nicht besuchten Vorträgen) zum großen Teil um die Darstellung und den Umgang mit den Ergebnissen von checks. Icinga bietet dafür in Zukunft ein sehr frei konfigurierbares Webinterface an, so daß sich damit jeder Betrachter seine spezifischen Views zusammenbauen kann - das neue Webinterface ist in PHP, damit ergeben sich dann die im web2.0 üblichen Dinge wie Ajax-Suche usw..

Icinga versucht, abwärtskompatibel zu Nagios zu bleiben (so lange es geht), gleichzeitig benötigt Icinga auf jeden Fall die Datenbankanbindung. Die Entwickler arbeiten daran, diese auf standard SQL zu bekommen, um andere DBRMS (PostgreSQL und Oracle) anbinden zu können. Daneben sind die Jungs dabei, eine universelle Schnittstelle zu entwickeln.

Die Präsentation hat deutlich gemacht, daß das Icinga-Team mit Hand und Fuß plant und dann entwickelt, und nicht im allgemeinen Fork-Chaos irgendwo Funktionen dranfrickelt - das gibt ein gutes Gefühl auf die folgende Entwicklung. Seit der Konferenz ist 1.0RC1 verfügbar.

Der 'gesellige Abend' war ok, allerdings waren die Tische etwas zu groß und die Mukke etwas zu laut, um sich in Ruhe austauschen zu können. Ich bin von dort dann trotz der weiteren Strecke zum Hotel gelaufen (gestützt durch Kristians und mein Handy-GPS - wie haben wir das nur früher hinbekommen) - wenn der Konferenzort auch noch der Schlafort ist, ist das zwar morgens sehr bequem, und man kann in Schluffen zum Vortrag, aber man bewegt sich quasi gar nicht mehr.

Der nächste Morgen begann mit check_mk als Alternative zu NRPE der sich im Nachhinein als mein persönliches Highlight herausstellende Vortrag. Wieder ein komplettes Konzept, bei dem deutlich wurde, daß der Entwickler nicht hirnlos angefangen hat, herumzubasteln, sondern vorher über eine Art Architektur für ein Tool nachgedacht hat.

check_mk ermöglicht durch die Verlagerung der nrpe-Konfiguration auf den Nagioshost eine Nichtkonfiguration auf dem zu checkenden Client - mit dem Pferdefuß, daß dies nur für stark normalisierte Standardsystemparameter funktioniert.

Die Vorteile des Konzeptes: Irre schnelles Ausrollen auf einer großen Anzahl von sehr heterogenen Clients, sehr einfache Möglichkeit der Überprüfung, ob evtl. Dinge dazugekommen sind, die man auch überwachen möchte, automatische Erstellung von 0815-Nagios-Konfigurationsdateien, irre Performance - weil check_mk einfach nur den Daemon auf dem Client anpiekst, und der alles auskotzt, was er weiß. D.h., es gibt nicht für jeden einzelnen Check eine Kontaktaufnahme.

Die Nachteile des Konzeptes: Im wesentlichen funktioniert das nur für wellknown Standardsystemparameter, es ist also super, um Eisen zu überwachen. Es ist ungeeignet, um sehr individuelle Checks zu verarbeiten, also genau das, was Anwendungsüberwachung eigentlich ausmacht. Bei nrpe kann ich einfach alle individuellen Anwendungschecks in die nrpe_local.cfg schreiben, diese global verteilen und via Nagios-Konfiguration jeweils pro Host genau die ansprechen, die ich dort brauche - bei check_mk muß man das dann anscheinend doppelt konfigurieren, also auf dem Client ins Scriptsverzeichnis kippen und auf dem Server entsprechend nach konfigurieren.

Insgesamt aber eine interessante Sache, die ich auf jeden Fall ausprobieren werde. Bei kurzem Nachdenken fallen mir sofort noch einige andere mißbräuchlinge Dinge ein, die man mit der Inventarisierungsfunktion von check_mk tun kann - z.B. per nmap alle Hosts vom Typ X (sagen wir mal Xen-VM) finden und dann mit check_mk -L trübertackern und die Systemdaten wegschreiben, nachdem man ins Skriptverzeichnis für Debian-Kisten z.B ein 'dpkg -l'-Aufruf gesetzt hat...
Außerdem scheint es auch ein logwatch-Flansch zu geben, da kann man diese Daten auch schön weiterverarbeiten.

Über das Gespräch mit Mathias Kettner hab ich dann den nächsten Slot verpaßt, aber das war auf der einen Seite die übliche Stockebrandt-IPV6-kommt-jetzt-bald-wirklich-Gedächnisveranstaltung und auf der anderen was über NConf, ein grafisches Enterprisekonfigurationstool. Nach (sehr kurzem) Nachdenken kommt man eigentlich darauf, daß zumindest ich in einer Enterprise-Umgebung Nagios-Dateien lieber maschinell (aus LDAP, per python-Parser, klassischem Makefile oder sonstirgendwie) aus dem svn lutsche und generiere denn über ein GUI zusammenklicke, aber da sind die Geschmäcker anscheinend verschieden.

Im Anschluß gab es eine Vorstellung des Monitorings in einer Enterprise-Umgebung, und zwar der von LindenLabs 2nd Life (auch deutlich über >10.000 Hosts).

Dort ist man den sonst üblichen Weg, die mit Nagios erzeugten Daten in einen grafischen Aufbereiter zu kippen, genau umgekehrt gegangen - so werden dort die Daten aus Ganglia, einem freien Monitoringsystem speziell für große Grids und Clustersysteme, an Nagios weiterverfüttert, um den Performance-Problemen mit z.B. aktiven Checks aus dem Weg zu gehen. Interessanter Ansatz, für das OP-Monitoring braucht man ja in der Regel nur einen Teilsatz der im grafischen Verlaufsmonitoring eh vorhandenen Daten.

Leider findet man auf der Ganglia-Webseite im ersten Schritt keine brauchbare Doku, ich hab das erstmal nicht weiter verfolgt.

Ganz zum Schluss gab es dann noch einen Vortrag zum Nagios-Benachrichtigungssytem, der zwar meiner Meinung nach sehr gut war, aber aufgrund des Themas wohl eher als einführender Vortrag an den Beginn der Veranstaltung gehört hätte.

Für die meisten wohl eher nix neues dabei, trotzdem fundiert und vor allem didaktisch sauber aufbereitet.

Zusammenfassung

Das Hotel, Unterbringung und das ganze Drumherum war super. Der Service war so gut, daß er fast schon genervt hat - wenn man beim letzten Bissen seinen Teller nicht mit Messer und Gabel verteidigt hat, wurde er einem sofort weggerissen und man mußte sich nen neuen holen.

Die Themen der Konferenz haben mich etwa zur Hälfte interessiert, und es waren zwei parallele Tracks. Leider waren ab und zu Sachen, die mich interessierten parallel. Wahrscheinlich läßt sich das nicht vermeiden, wenn man Wert darauf legt, daß es immer einen deutschen und einen englischen Vortrag parallel gibt, um sowohl internationale Besucher als auch (ältere) deutsche Besucher entsprechend abzuholen.

Die Besucherstruktur fand ich für eine OpenSource-Konferenz eher ungewöhnlich, nur wenig bekannte Gesichter, die auch nur wenig auf die bekannten Gagstarter (... you are currently dying...) reagierten. Nach meinem Eindruck viele Leute, die ohne großen OSS-Hintergedanken Nagios einsetzen (weil es augenscheinlich am meisten bäng for the bugs gibt) oder beim Veranstalter Kunden sind und nur darüber auf OSS-Konferenzen auftauchen. Nichtsdestotrotz haben sich viele interessante Gespräche und einige Kontakte ergeben.

Aus den Gesprächen nebenbei hat sich immer wieder ergeben, daß viele Besucher Mehrfachtäter sind und sich oft als Community-Members aus den Nagiosbenutzer-Selbsthilfeforen (z.B. Nagios-Portal oder Monitoring Exchange) kennen.

• Ich nehme mit, daß opensource monitoring in der Regel wie 'nagios' ausgesprochen wird. Hoffentlich ändert sich das bald auf 'icinga'.
• Ich nehme mit, daß ich mich mit check_mk beschäftigen werde und wahrscheinlich auch mit jmx4perl.
• Ich nehme mit, daß die Probleme, die die meisten Konferenzteilnehmer drücken (grafische Aufarbeitung, Konfiguration und Auswertung) für uns keine sind.
• Ich habe den Eindruck, daß ich bei einem ernsthaften Problem mit Nagios die vorhandenen Foren und Boards vergessen kann, zumindest, wenn ich eine Antwort will.
• Ich nehme einige Antworten auf Fragen mit, die ich nie gestellt hätte.

Insgesamt hat es sich auf jeden Fall gelohnt, an der OSMC teilzunehmen.

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]