Jetzt ist es bald soweit und die OSMC 2019 steht an, da fällt mir auf, dass ich zwar letztes Jahr meinen gewohnten Bericht geschrieben, aber nicht veröffentlicht habe. Um eure Vorfreude zu steigern hole ich das jetzt einfach mal nach.

Es war mal wieder November, das heißt auch, es was mal wieder OSMC. Eine der IT Konferenzen, die ich am längsten und am häufigsten besuche. Woran das wohl liegen mag? Das möchte ich euch nicht in den Mund legen, lest einfach meinen Bericht und ihr könnt für euch selbst entscheiden, warum man die OSMC so genial finden sollte. Neben den von mir unten angesprochenen Vorträgen gab es noch eine ganze Reihe weitere, sehenswerte Vorträge. Die Netways Kollegen haben wie immer alles veröffentlicht und jeder kann mal reinschauen, unter https://osmc.de/2018-2/videos-and-slides/.

Interessant ging es gleich los mit einem Vortrag von der @sys_adm_ama. Mit dem Thema “Smart Home Monitoring mit OpenHAB2”. Obwohl ich mich mit dem Thema SmartHome eher nicht so beschäftige, habe ich doch ein gewisses interesse  daran. Grundvoraussetzung für mich ist aber, dass ich meine Daten nicht in irgendeine Cloud schieben muss, nur um eine warme Heizung zu haben.  Gleich zu Anfang hat mich die Tetris Uhr, die auf einem der Tische stand, schon ein wenig fasziniert, später habe ich dann noch erfahren, dass die hauptsächlich teuer und eigentlich gar nicht so gut sein soll, aber das tut ja erstmal nichts zur Sache. Jetzt mal zum Inhalt des Vortrages. Er war auf jeden Fall sehr Informationsgeladen und mitreißend. Was will man sonnst von der Frau erwarten, die das deutsche Buch über OpenHAB2 geschrieben hat. Anfreunden konnte ich mich mit der Sichtweise, dass Heimautomatisierung eigentlich nur die eigene Faulheit unterstützt, davon habe ich auch mehr als genug und alles was das unterstützt ist mir sehr wilkommen. Auch so nervenraubende Themen, wie die Frage “Habe ich die Kaffeemaschine ausgeschaltet?”, können einem durch eine gute Installation abgenommen werden. Da wird es schon interessanter. Wer das Ganze aber für die Energieeffizienz im Haus einsetzen will, ist warscheinlich erstmal mit anderen Schritten, wie z.B. einem neuen Brenner für die Heizung, besser bedient. Später kann man das ja noch ausbauen und allerhand abenteuerliche Konstruktionen und Sensoren dazu stopfen um wirklich alles auszuwerten. Ein ganz großer Nachteil der ganzen SmartHome Lösungen ist die Vielfalt an Herstellern, die unbedingt alle ihre eigene Cloudlösung, ihre eigene App und ihr eigenes Protokoll für ihre Geräte entwickeln wollen. Haben wir diese Fehler nicht schonmal gesehen und hat es uns nicht gerade 20 Jahre gekostet diese Fehler auszumerzen? Warum fangen jetzt schon wieder alle damit an? Zum Glück tritt OpenHAB2 mit dem Ziel an, alle diese Geräte anbinden und sie gemeinsam verwalten zu können. Warum muss eigentlich immer eine OpenSource Lösung den Firmen zur Hilfe kommen, damit mal etwas richtig gemacht wird? In OpenHAB2 selbst kann man die angebundenen Geräte auslesen und über Regeln miteinander verknüpfen. Dadurch lassen sich sehr komplexe Abläufe erstellen und das kann auch sehr schnell unübersichtlich werden. Generell ist der Vergleich zur Software Architektur gar nicht unpassend. Wenn man viele Komonenten ungeplant und chaotisch miteinander verknüpft, schafft man sich ein Rezept für ein Desaster. Planung und Sauberkeit sind nicht zu verachtende Tugenden für diese Aufgabe! Abschließend kann man festhalten, Heimautomatisierung ist ein spannendes Betätigungsfeld in dem man sehr viel Zeit versenken kann, aber dafür macht es unheimlich viel Spaß!

Als zweiten Vortrag hatte ich mir “Scaling Icinga2 with many heterogenous Projects” von den SysEleven Leuten herausgesucht, von denen hört man ja auch viel Gutes! Ich war dann auch sehr positiv überrascht, als sie ihre große, heterogene Umgebung beschrieben haben, und das Ganze genau wie bei uns klang. Und sie haben auch sehr ähnliche Probleme, wie wir selbst. Vor allem die separierten Projekte und die Unterschiede zwischen den einzelnen Anwendungen/Kunden stellen nochmal besondere Anforderungen an ein Monitoringsystem. Und auch die SysEleven hatte das gleiche Ziel wie wir, sich ein 100% automatisiertes Monitoringsystem aufzubauen. Schön war es vor allem die direkten Parallelen zu sehen und auch alternative Lösungen zu vergleichen. Eine der wichtigen Erkenntnisse war für mich das, wass ich den Kollegen bei uns auch immer sage: “Migrieren ist härter als neu bauen, weil man alles verstehen muss und dann so umbiegen, dass es wieder genau so funktioniert, wie vorher”. Aber auch bei SysEleven hat man sich am Ende dazu entschlossen, die alte Konfiguration – inklusive NRPE Konfiguration – zu übernehmen. Dabei ist dann sogar noch ein schönes Tool entstanden um Konfigurationen zu vergleichen (icinga2-migration-utils). Sehr schön fand ich auch die Anpassungen, die am Icingaweb Frontend durchgeführt wurden, um SLA und Dokumentationslinks unter zu bringen. Damit hat man dann im Fehlerfall gleich alle nötigen Informationen griffbereit, sehr praktisch! Ebenso gut fand ich die Aufforderung am Ende: Sprecht über eure Setups und teilt eure Erfahrungen, das ist das Wertvollste überhaupt, was man in der Community teilen kann!

“Sprecht über eure Setups und teilt eure Erfahrungen, das ist das Wertvollste überhaupt, was man in der Community teilen kann.“

Der nächste Vortrag, der mich in seinen Bann zog, war “Netwerkmonitoring mit Prometheus”. Das schien auch für viele andere Besucher ein interessanter Vortrag zu sein, denn der Raum war bis zum bärsten voll! Am Anfang gab es eine Kurzeinführung in Prometheus, und einen kleinen Seitenhieb auf Cacti. Dabei viel mit auf, dass Cacti zwar inzwischen eher veraltet erscheint und auch nicht die besten Bewertungen bekommt, aber dennoch ist es noch in sehr vielen Umgebungen aktiv im Einsatz und wird offenbar oft als “gut genug” empfunden. Aber zurück zu Prometheus, dieses ist eigentlich so aufgebaut, dass es die Monitoringdaten von den zu überwachenden Geräten abfragt und dann speichert. Also könnte man ja naiv denken, dass man einfach die APIs der Hersteller verwenden kann und dann ist alles gut. Leider mussten die Vortragenden dabei die gleichen Erfahrungen wie wir machen. Die APIs der Hersteller sind oftmals viel zu langsam, fehlerhaft oder erzeugen zu viel Last auf den Netzwerkgeräten. Also landet man am Ende wieder bei SNMP. Was man davon hält, kann jeder für sich entscheiden, in meinen Augen ist das im Zeitalter von SDN und Cloudlösungen nur noch ein weiterer Sargnagel für die klassische IT Hardware. Nicht umsonst bauen sich Unternehmen wie Facebook ihre eigenen Switches, die komplett auf Linux laufen. Aber ich drifte schon wieder ab. Jedenfalls wurde im Vortrag dann ein SNMP Exporter vorgestellt, der die nötigen Daten via SNMP abfragt und es wurde erläutert, wie man das am besten einrichten kann. Zusätzlich gibt es für den Exporter noch einen Config Generator, mit dem man alle nötigen Konfigurationen automatisieren und sogar zur Laufzeit anpassen kann.  Abschließend wurde dann noch das Frontend mit Grafana gezeigt und eine Einbindung in Thruk. Diese fand ich sehr interessant. Das Grundproblem dabei war, dass man Monitoringdaten immer nur in relativ langen Zeitabständen erhebt, z.B. minütlich. Bei einigen Problemen braucht man aber viel hochfrequentere Datenmessungen, diese sind aber leider sehr lastintensiv, wenn man sie überall dauerhaft laufen lässt. Also wurde das Frontend von Thruk so erweitert, dass man einen “Debugmodus” aktivieren konnte und dann das Monitoring für eine konkrete Komponente entsprechend erweitert wird, bis man den Debugmodus wieder verlässt. Eine sehr schöne Idee und vor allem in Netzwerkbereich sehr sinnvoll!

Nach einem gehaltvollen Mittagessen ging es weiter mit “Building a healthy oncall culture”. Der Focus des Vortrags lag zu Anfang vor allem auf den Stressfaktoren, die Rufbereitschaften bei den “Betroffenen” auslösen. Damit kann sich sicher jeder, der selbst schonmal eine Bereitschaft leisten musste, identifizieren. Weiter ging es mit der Frage, wie man damit am besten umgehen kann. Als Grundlage wurden in diesem Beispiel Regeln formuliert, an die sich alle Kollegen halten sollen. Wichtige Eckpunkte sind dabei Transparenz, also Klarheit über Verantwortlichkeiten innerhalb der Rufbereitschaft und der nötige Freiraum um diese leisten zu können. Das bedeutet im Besonderen, dass man von einem Rufbereitschaftler wärend der normalen Arbeitszeiten keine Höchstleistungen abverlangen kann. Weiterhin sollte die Aufteilung der Bereitschaften fair sein. Also alle Kollegen gleichmäßig und mit genügend Erhohlungszeit an der Reihe sein. Auch Entwickler sollten gelegentlich mal zur Bereischaft herangezogen werden. Für neue Kollegen ist ein Shadowing, also die Begleitung der Bereitschaft durch einen erfahrenen Kollegen, sehr empfehlenswert. Das schafft Sicherheit für die betreute Applikation und auch für die betreuenden Kollegen. Schließlich sollte jeder Bereitschaftseinsatz in einem blameless Postmorten ausgewertet werden. Das Ziel muss sein, dass ähliche Probleme nicht nochmal in der Bereitschaftszeit gelöst werden müssen.

Weiter ging es danach mit einem sehr unterhaltsamen Talk über “Handling messages and notifications from software and gadgets with MQTT and mqttwarn” von Jan-Piet Mens. Für mich war das eine schöne Erklärung, warum es MQTT gibt und wie man es nutzt. Teil des Vortrags war auch eine detaillierte Erklärung, wie MQTT funktioniert. Gegen Ende hatte dann auch noch das Publikum eine Aufgabe, man könnte also sagen, das war “MQTT zum Anfassen”. Natürlich ging es dabei auch um das Thema Monitoring und wie man MQTT Systeme überwachen kann.

Danach habe ich mir für “Distributed Tracing FAQ” entschieden. Ein Thema das in der wunderschönen neuen App- und Cloud-Welt immer relevanter wird. Tracing in einer monolithischen Anwendung ist relativ einfach, da man genau einen Punkt hat, an dem man überwachen muss. In einer verteilten Architektur muss man zuerst alle Teilsysteme verknüpfen, so dass man sehen kann, welche Teilaktionen zu einer globalen Anfrage/Aktion gehören. Und genau das ist der große Knackpunkt im Distributed Tracing – das verfolgen von Anfragen über Applikationsgrenzen hinweg. Das Ökosystem um Open Tracning ist relativ fragmentiert, aber Openracing tritt an, um einen gemeinsamen Standard zu etablieren. Ich habe mir noch mitgenommen, dass man für eigene Versuche Tools wie Jaeger oder OpenZipkin nutzen kann. Und ich habe schon das perfekte Projekt um das mal zu testen.

Ein Vortrag, auf den ich mich immer freue, ist der “Current state of Icinga” von Bernd Erk.  Wie gewohnt zuerst mit einem Blick in die Vergangenheit, dieses Jahr wurde sehr viel Arbeit und die Integrations und Stabilität investiert. So kann Icinga2 mit minimalem Ressourcebedarf selbst in größten Umgebungen eingesetzt werden. Ein schöner Nebeneffekt ist natürlich auch, dass es dadurch auch als Performant und schnell in der Nutzung und Alarmierung wahrgenommen wird.  Dann ging es weiter mit den aktuellen Entwicklungen. Diesmal wurde wieder sehr viel am Director geschraubt. So gibt es jetzt Unterstützung für das Verwalten multipler Icinga2 Instanzen, Baskets um die Konfiguration zu exportieren und in andere Director Instanzen wieder zu importieren. Und Icinga hat jetzt Namespaces gelernt! Alles Features, die auf eine Erweiterung für Multi-Tenancy hinwirken. Etwas was unseren Plänen für unser zentrales Monitoringsystem sehr zu gute kommt! Zusätzlich wurden zwei neue Module veröffentlicht, eines für x509 Zertifikatsmonitoring und eines für die integration von vCenter Ugmebungen. Beides ist für ein Enterprise Umfeld sehr gut nutzbar und eröffent viele neue Möglichkeiten um das Monitoring besser zu automatisieren. Das vShpere Modul hat sogar noch den Vorteil, dass es viele der Statusinformationen aus vCenter anzeigen kann, und das in einer Geschwindigkeit, die die vmware Tools wohl nie erreichen werden. Für die Zukunft steht uns der Abschied von der IDO Datenbank und eine Migration der Stautsdaten in Redis bevor. Dadurch soll alles noch schneller werden und einige Ansichten auch mit mehr Informationen angereichert werden. Zum Abschluss bleibt uns noch die Erkenntniss, das Live Demos zwar das geilste sind, was macn machen kann, aber leider nicht immer gut gehen. Aber darüber kann man doch hinwegsehen, ob des gewaltigen Entwicklungswillens in der Icinga Community.

Als letzter Vortrag des Tages stand noch der “Werkstatttalk mit Authoren” auf meiner Liste. Bei diesem haben sich die anwesenden Buch und Online Authoren in einer lockeren Gesprächsrunde zusammengefunden und über ihre Erlebnisse und Erfolge berichtet. Es war schon sehr spannend mit anzuhören, was man so als Buchauthor so alles erleiden muss. Wenn man von seinem Geschriebenen leben will, scheint der Weg über Fachartikel weitaus vielversprechender zu sein. Die Grundmeinung war auch, dass man ein Buch nur schreibt, weil man etwas zu sagen hat und der Community oder seinem Ego etwas spendieren will. Auch über Handwerksmittel wurde geredet, dabei war der Konsens dass vi und LaTeX zusammen das einzig Wahre sind. Word wurde kurz abgesprochen und mit schallendem Lachen wieder begraben.

Nun war es aber erstmal Zeit für die Abendveranstaltung. Diese war, wie von Netways gewohnt, eher überschwänglich und sehr sehr unterhaltsam. Ich habe die Zeit genutzt um mit einigen Telekom Kollegen zu reden und auch noch mit vielen alten und neuen anderen Kontakten mal wieder ins direkte Gespräch zu kommen. Und bevor ich es mich versah, war es auch schon um 5. Aber das war gar kein Problem, einfach noch einen Gute-Nacht-Döner essen und dann erstmal schlafen gehen. Das Aufstehen am nächsten Morgen war mühselig, aber getragen von den interessanten Gesprächen des Vorabends war es mir dann doch möglich, mich aufzuraffen und weiteres Wissen in mich aufzunehmen, essen ging jedenfalls erstmal noch nicht.

Und so ging dann der erste Vortrag über “Observability in a Microservice World” los. Es war eine schöne Betrachtung, wie man an das Thema herangehen kann. Ausgehend von der Aussage, dass Software nur für den Erschaffer durchschaubar ist, für alle anderen ist sie  per se undurchsichtig. Wie löst man dieses Problem? Man muss also die Obersavbility erst schaffen, im Normalfall geschieht das durch gutes Logging. Aber was bedeutet “gut” in diesem Kontext? Das kann man erreichen, in dem man beim Schreiben der Logs die perspektive des Lesers einnimmt. Ähnlich wie bei einem guten Buch. Dann wurde auf einige konkrete Tools genauer eingegangen, in Java sind da z.B. MDC und Spring Micrometer zu nennen. Wenn man Logs schreibt, sollte man sie ebenfals gleich in ein zentrales Loggingsystem transferieren und nicht erst in einzelen Logfiles auf der Festplatte zwischenspeichern. In einer Microservice Umgebung sind diese Logs alleinstehend sowieso nicht sauber auswertbar und sie machen das ganze Systemverhalten schwer berechenbar, da Loggrößen, IO und Historien variieren können. Generell Kann man sagen, dass zentralisiertes Logging zusammen mit Tracing und Metrik Monitoring das Dreamteam für Applikationsanalysen sind. Grundsätzlich muss das Ziel dieser Lösung sein, Probleme zu analysieren, die man noch nicht kennt, sonnst bleibt man ewig im reaktiven Modus. Der Fokus liegt weniger darauf bereits bekannte Dinge zu überwachen. Das ist am Ende nur ein netter Nebeneffekt.

Als nächstes stand mir eine schwere Entscheidung bevor. Zwei ähnlich gut klingende Vorträge. Ich habe mich dann für “Monitoring of Software Defined Networks” entschieden und will mir den “Mit KI zu mehr Automatisierung bei der Fehleranalyse” Talk noch als Aufzeichnung ansehen. Der SDN Talk fing sehr schön an, mit der Frage, warum man eigentlich SDNs will? Man virtualisiert das Netzwerk und kann so die Datenebene von der Managementebene trennen. Das schafft Sicherheit für die Administration. Außerdem kann man im Underlay Netzwerk sehr simple Konzepte für Redundanzen und Lastausgleich implementieren. Alle komplexen Technologien und die Feinheiten laufen im Overlay Netzwerk. Das virtualisiert das komplette Netzwerk, es wird also komplett von der physischen Struktur entkoppelt. So lassen sich komplexe Konzepte umsetzen ohne zu viele Nebeneffekte und Verstickungen. So kann man das gesamte underlay Netzwerk z.B. mit BGP realisieren, dabei ist jeder einzelne Switch ein BGP AS und peert mit allen seinen angeschlossenen Nachbarn. Dadurch kann man durch ein simples Traceroute sehen, welchen physischen Weg die Pakete nehmen. Vorzugsweise setzt man gleich Switches auf Linux Basis ein, das macht Administration und Monitoring noch einfacher. Aber wie monitort man das jetzt genau? Auf der Netzwerkebene ist meißtens eine schnelle Analyse wichtiger als das eigentliche Monitoring, und so sollte man sich auch auf das Sammeln möglichst aller relevanten Metriken konzentrieren. Denn im Fehlerfall hat man entweder Daten oder nicht. Leider weiß man vorher nur sehr selten, was man genau benötigt um die Analyse durchzuführen.

Weiter ging es mit “What We Should All Worry About When Monitoring Serverless Applications”. Interessant war hier vor allem, wie anders man Monitoring interpretieren muss, wenn man keine Server mehr hat. Vieles reduziert sich auf Logging und Metriken. Aber auch Teile der Applikationen selbst müssen eigene Abschnitte für Mointoringähnliche Funktionen haben.

Der vorletzte Vortrag war einer der Besten der ganzen Konferenz mit “Icinga2 Scale-Out – Monitoring großer Umgebungen” hat Jens Schanz sein schönes Monitoringsystem beschrieben, welches eine wahrhaft riesige Umgebung überwacht. Das gesamte Netzwerk bei DM ist so riesig, dass hier selbst Icinga2 an seine Limits kommt. Aber das konnte bisher zusammen mit Netways immer weiter verbessert werden, so dass es zu keinem kritischen Problem geworden ist. Aber wie verwaltet man eine solche große Umgebung? Man muss automatisieren, sonnst wird man wahnsinnig! Und man muss aufhören in einzelnen Servern zu denken, man muss die Infrastruktur als gesamtes betrachten und seine Überwachung darauf auslegen. Zusätzlich helfen noch ein paar UI Tweaks, um z.B. gleich Beschreibungen und Dokumentationen neben den Checks anzuzeigen. Und als herzliche Empfehlung gab es noch ein:

“Lasst NRPE endlich sterben, Icinga Agents sind besser und sind das, was ihr eigentlich wollt!“

Den Abschluss der Vorträge bildete “Eliminating Alerts or ‘Operation Forest’”. Und zum Abschluss gab es nochmal etwas richtig Gutes! Viele Opsler denken, dass Alerts etwas Gutes sind, und man in jedem Fall einfach mehr davon braucht. Aber genau das ist ein Irrglaube, viele Alarme führen nur zu Abstumpfung und “Alert fatigue”. Als Erstes sollte man darauf achten, dass nur kritische Probleme, bei denen wirklich ein Eingriff nötig (und möglich) ist, alarmieren. Der Rest sind nur Informationen im System. Dabei ist wichtig anzumerken, dass die Alerts selbst nicht das Problem sind, die fehlerhafte Kultur im Umgang damit ist das eigentliche Problem! Eine schöne Analogie dazu ist: Rote Checks sind wie Müll im Wald, auch wenn man sie kennt und sie einem nicht gehören, sollte man sie wegräumen, sonnst türmen sie sich auf. Dabei sollte die Grundprämisse sein: Kenne deine Applikationen und keinne dein Monitoring! Das geht bis zu dem Punkt, an dem man feststellt, dass es im Monitoring keine “false Positives” gibt, das sind, wenn man ehrlich ist, Konfigurationsfehler. Und diese muss man beseitigen. Zum Ende des Vortrages wurde noch eine Negativcheckliste vorgestellt, mit der man prüfen kann, wie schlecht man wirklich ist. Einige der Punkte regen definitiv zum weiteren Nachdenken an.

Und damit ging eine aufregende und informative Konferenz zu ende. Ich kann nur sagen, das es einfach toll war. So viel Kompetenz und gleichzeitig familiäre Gemütlichkeit erlebt man selten an einem Ort. Ich bin auf jeden Fall immer wieder gerne auf der OSMC!

Neugierig geworden? Noch mehr Konferenz-Erlebnisse gibt es hier:

Lade mehr

Mit Freunden teilen

> Zuerst Social Funktionen aktivieren