Fully packed to reduce heating – OSMC 2016 – Tag 3

OSMC Logo
Nach zwei interessanten Tagen mit Vorträgen ging es heute zum Abschluss wieder ans gemeinsame Hacken beim Hackathon. In einer kurzen Vorstellungsrunde kristallisierten sich bereits die Themen heraus und es ging sofort ans umgruppieren um den gemeinsamen Interessen zu folgen.

Neben viel Erfahrungsaustausch, migrierten Monitoringumgebungen, internen Skripten rund um Icinga 2, umgebungsspezifischen “Icinga Web 2”-Modulen und Prototypen wie “Icinga 2”-SNMP-MIBs und Debian-Packages für NSClient++, gibt es auch tatsächlich Ergebnisse zu vermelden.

Hackathon

* Das neue Puppet Module für Icinga 2 erhielt Unterstützung für SLES 12 (Pull-Request on Github)
* Die “Icinga 2”-Vagrant-Boxes erhalten Proxy-Support (Pull-Request on Github)
* Der Prototyp eines Elastic-Icinga-Beat (Prototype on Github)
* Das mit Dashing-Icinga2 zur Verfügung gestellte Dashboard wurde um weitere Funktionalitäten erweitert (Commit bereits gemerged)
* Das “Icinga Web 2”-Module NagVis wurde erweitert, unter anderem um Zoom für Dashboards (Commit bereits gemerged)
* Icinga Web 2 kann nun konfiguriert werden um Standalone zu laufen (Patch verfügbar)
* Neben einem kleinen Fix wurde dem Foreman-Smart-Proxy Monitoring-Plugin beigebracht Hosts in Icinga 2 anzulegen (Feature-Branch auf Github)
* Einen adaptiven Http-Check (Repository auf Github)

Ich würde es bei diesem Output als einen erfolgreichen Hackathon bezeichnen!

P.S.: Wer viel auf Github unterwegs ist, dem möchte ich noch den Artikel zum Erstellen eigener Labels ans Herz legen. Der erwähnte Smart-Proxy hat nun farblich korrekte Labels für Icinga 2 und Zabbix.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

Fully packed to reduce heating – OSMC 2016 – Tag 2

OSMC LogoDer gestrige Tag endete in lockerer Atmosphäre in der Indabahn, die wir nach ein paar Jahren am Flughafen wieder zur Abendlokation erkoren hatten, und für die Ausdauernden in Checkpoint Jenny, unserer üblichen Late-Lounge. Aufgrund unserer Rekordteilnehmerzahl gab es auf der Abendveranstaltung ein Running Buffet, so dass man einfach entspannt sitzen bleiben und sich unterhalten konnte und trotzdem gut mit Essen und Getränken versorgt wurde. Für weitere Unterhaltung war mit mehreren Roulette-Tischen gesorgt, an denen natürlich nicht um echtes Geld sondern um die Platzierung und damit den Preis für den ersten Platz gespielt wurde.

Trotz allem hatte Mario Mann volles Haus für den ersten Vortrag “Application Performance Management with Open-Source-Tooling” des Tages. Primär ging es um InspectIt welches Mario sowohl kommerziellen Tools gegenüberstellte als es auch in die Landschaft der “Open Source”-Monitoring-Tools einordnete. Auch hier drehte sich alles um Metriken, diesmal zur Erkennung von Anomalien in der Anwendungsperformance, und um die weiteren Daten um diese Anomalien richtig einzuordnen. Ein weiteres nettes Werkzeug, das ich aus dem Vortrag mitnehme ist WebPagetest.org.

Der “Engineer’s guide to Data Analysis” von Avishai Ish-Shalom spannte die Teilnehmer direkt ein um Problemanalyse auf Basis von Metriken zu betreiben. Ein paar der erlernten Lektionen: Durchschnittswerte sind nicht gut, die schlechtesten 5% (oder 1%) und möglichst nicht aggregierte Daten zeigen das Problem deutlicher. Aggregation ist nötig um die Daten speichern zu können, allerdings muss man im Vorfeld wissen wie man die Daten nutzen will um sie richtig zu aggregieren. Dies gilt auch für die graphischen Tools, die automatisch Daten zur Anzeige aggregieren.

“What’s Happening with OpenNMS” war der Update-Vortrag zu OpenNMS von David Hustace. Auch OpenNMS hat eine stetig wachsende Community und Feature-Liste, mit den üblichen Verdächtigen wie API und Grafana-/Elasticsearch-Integration. Die Integration von Backshift und R zur Darstellung von Graphen erlaubt eine richtige schöne Interaktion mit den Daten wie beispielsweise Live-Analyse und Vorhersage für Trends. Das neue BusinessProcess-Tool sieht auch sehr interessant aus, in der Icinga-Welt würde ich es als Mischung aus dem BusinessProcess Modul und NagVis bezeichnen. Allgemein kann man sagen viel Modernisierung hat in den letzten Monaten stattgefunden und wird es in den nächsten noch weiter tun.

Frisch gestärkt ging es nach dem Mittagessen weiter mit Thomas Niedermeier und “Hello Redfish, goodbye IPMI – The Future of Hardware Monitoring”. Nach einem Abriss warum man Remotemanagement einsetzen sollte und warum IPMI nicht mehr zeitgemäß ist, ging es um Redfish welches seit 2014 versucht eine moderne Lösung für diese Aufgabe darzustellen. Die Lösung basiert auf einer REST-API mit entsprechender Authentifizierung. Wer will kann also schon mit einem einfachen Browser-Plugin oder etwas python-Code arbeiten, die DMTF liefert allerdings sogar schon entsprechende einfache Tools. Es sieht also aus als könnte in naher Zukunft das IPMI-Protokoll zu Gunsten von Redfish abgeschaltet werden.

Nach seinem Vortrag fand dann auch gleich die übliche Hardware-Verlosung statt bei der Thomas-Krenn sich als Sponsor wie üblich nicht Lumpen gelassen hat und so durften drei Teilnehmer mit einer neuen Laptop-Tasche, SSD oder gar Mini-Computer nach Hause gehen. Ebenfalls wurde der Roulette-Gewinner der Abendveranstaltung mit einer smarten Waage beehrt, die man nach einer OSMC sicherlich gebrauchen kann.

Jan Doberstein mit “Take Care of your Logs” machte deutlich warum Logging wichtig ist und warum man Log-Events zentral sammeln sollte. Vom einfachen zentralen Syslog-Server über den Platzhirsch Elastic Stack ging es zu Graylog, welches einem gesamtheitlichen Ansatz folgt um Logs zu normalisieren und anzureichern um sie möglichst hilfreich zu präsentieren. Klarer Vorteil bei Graylog ist und bleibt die schöne Zugriffsteuerung auf die gesammelten Daten. Für Neugierige sei gesagt, dass die Open Beta der nächsten Version kurz vor der Veröffentlichung steht, die es noch flexibler machen wird.

“Software Development seen from a #yolo^Wdevop” von Jan Wagner aus dem Monitoring-Plugins-Projekt zeigte wie sich die Entwicklerwerkzeuge vom Texteditor zu heutigen Toolchains weiterentwickelt haben (inklusive YoloOps Bingo). Ich kann nur sagen ein schöner Einblick in das Projekt und eine nette Auswahl an Tools.

Ich fand es mal wieder eine sehr schöne und interessante Konferenz. Meinen Dank dafür an alle Speaker und Teilnehmer. Ich wünsche allen, die nicht zum Hackathon bleiben können, eine gute Heimfahrt und wir sehen nächstes Jahr am 21. bis 24. November wieder.

Bilder folgen!

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

Ein Buch über Icinga 2

Erscheint am 27. Juni 2016

 
41suqaLOyCL._SX336_BO1,204,203,200_April 2015, nach Monaten des Schwankens machten sich dann zwei verbliebene Möchtegernautoren doch auf ein Buch zum Thema Icinga 2 zu verfassen. Wir wollten ein sehr praxisnahes Werk mit vielen Beispielen wie und mit welchen Plugins etwas zu überwachen ist. Herausgekommen sind 344 Seiten von denen sich 100 mit Plugins und deren Verwendung in Icinga 2 befassen. Vorweg erfolgt eine generelle Einführung, die Vorstellung des neuen Webinterfaces Icingaweb 2 als auch eine ausführliche Erläuterung wie man lokale Werte wie Load bzw. CPU bei Windows oder Disk Usage mit NRPE/NSClient++, SSH und selbstverständlich mit dem neuen Icinga Agenten ermittelt.

Dem Kapitel über Plugins ist noch die Vorstellung einer fiktiven Firma vorangestellt. Diese betreibt ein zweigeteiltes Netzwerk mit einem internen Netz und eine durch Perimeter abgetrennte DMZ. Anhand dieses Beispiels wird eine verteilte Überwachung implementiert. Im internen Netz ist ein Icinga-Server (Master) für die Überwachung der dortig angesiedelten Server und Dienste zuständig. Für die DMZ wird ein weiterer Icinga-Server (Satellit) verwendet, der die ermittelten Ergebnisse an den Master meldet.

Diese Icinga-2-Infrastruktur wird dann im Folgenden benutzt, um eine Vielzahl von Diensten zu überwachen:

  • Host Erreichbarkeit
  • Zeitserver und lokale Zeit
  • Webservices incl. Apache und Ngnix
  • Domain Name Services
  • DHCP
  • Kerberos
  • Mailempfang und -versand
  • Proxy-Server
  • Generische Portüberwachung am Beispiel von Jabber
  • Javabasierte Application-Server
  • SAP
  • Kibana
  • Microsoft-Infrastrukturdienste: CIFS, Terminalservice, Domaincontroller, Exchange
  • Datenbanken: MySQL, PostgreSQL, MS SQL, Oracle
  • LDAP
  • Redis
  • Elasticsearch
  • VMware vSphere
  • Hardware: IPMI, HP, Oracle Solais, Thomas Krenn, Netzwerk, Festplatten
  • NetApp
  • Qnap

Das letzte Drittel ist Graphing mit PNP4Nagios und Graphite, Logmangement, Reporting und Businessprozessen gewidmet.

Teilbereiche werden von den beiden Autoren in einem Workshop vor der diesjährigen Open Source Monitoring Conference mit den Teilnehmern zusammen praktisch umgesetzt.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Monthly Snap May: Docker, Graphite, Opennebula and Beijing

May started with Simons blog post on monitoring custom applications. 

Blerim gave us an insight into Graphite – the history of a data point. Kai, one of our trainees explained what he learned at NETWAYS.
weekly snap

Tobias explained Debugging with Docker and Michael told us something about Docker on OSX.

Kay explained on how to get started with the Opennebula API.

Finally, Christoph told us about his Consulting journey to Beijing.

Vanessa Muschweck

Autor: Vanessa Muschweck

Vanessa ist unser Head of Finance und somit mit ihrem Team für das Geld, Controlling und Personalverwaltung zuständig. Außerhalb des Büros ist sie sportlich unterwegs und widmet sich neben Tennis hauptsächlich dem professionellem Yoga. Hier macht sie gerade die offizielle Trainer-Ausbildung und kann dann die älter werdende Belegschaft bei NETWAYS ertüchtigen.

Graphite – Die Geschichte eines Datenpunkts

Graphitgraphite-logoe ist tot. So zumindest ist die Meinung vieler auf Twitter und Co. Ein ganz anderes Bild zeigt sich allerdings in den Github Repositories. In kurzen Zeitabständen wird von mehreren Entwicklern commited. Bugs werden gefixt und Features implementiert. Die Geschwindigkeit, in der es Releases gibt, könnte natürlich schneller sein. Software wird aber nicht automatisch besser durch hohe Versionsnummern, das haben andere schon oft bewiesen. Das Projekt ist also alles andere als tot. Ganz im Gegenteil, sogar ein schönes neues Logo gibt es.

Was unser Interesse geweckt hat

Doch was ist es, das Graphite so interessant für viele Devs und Ops macht? Die I/O die es auf den Festplatten verursacht ist es mit Sicherheit nicht. Auch das verwalten dieser Whisper Dateien, samt Storage Schema und Aggregation Methods bereitet vermutlich den wenigsten von uns Spaß. Graphite hat etwas gebracht, was kein anderer auf diese Art und Weise hatte: eine API auf Metriken. Nicht nur das, sogar Funktionen zum Gruppieren, Transformieren und Filtern sind enthalten. Plötzlich ist es so einfach, Datenpunkte darzustellen und Graphen in eigene Tools einzubauen. Dem Kollegen mal eben einen maßgefertigten Graphen schicken? Kein Problem. Was bei RRD noch zu Kopfschütteln und knirschenden Zähnen, noch schlimmer: zu Perl Skripten geführt hat, ist nun ganz einfach und selbstverständlich. Graphite hat die Art und Weise wie wir mit Graphen umgehen verändert. Und das ist auch gut so.

Wichtig beim Thema Skalierung: SSDs

Das Thema der Skalierung ist und bleibt dennoch eine Herausforderung. Weil es eben so einfach zu verwenden ist, landen mit der Zeit mehr und mehr Daten in der Datengrube. Das System muss mitwachsen, andernfalls besteht die Gefahr, Daten zu verlieren. Es werden viele kleine Datensätze in kurzen Zeitabständen geschrieben. Am besten kann das natürlich mit SSDs abgefangen werden. Wem SSDs für das Gesamtsetup zu teuer sind, der kann sich mit Facebooks Flashcache einen Cache basteln und die permanente Lagerung auf mechanische Platten verschieben.

Die Geschichte eines Datenpunkts

So ein Datenpunkt beginnt seine Reise in der Regel auf einem Server. Dort wird er aufgesammelt von einem Collector, beispielsweise CollectD, Icinga2 oder Diamond. In voller Geschwindigkeit geht es dann Richtung Graphite. Sofern das Setup nicht minimal gehalten wurde, wartet dort eine ganze Kette an Carbon Daemons, angeführt vom Carbon Relay. Diese erste Aufprallstelle nimmt alle Metriken entgegen und verwaltet sie in Queues. Jedes nachgelagerte Ziel (Aggregator oder Cache) bekommt seine eigene. Wie voll diese Queue ist, hängt davon ab, wie schnell die Anschlussstelle (Aggregator oder Cache) die Metriken abarbeiten kann. Läuft diese Queue voll, werden Datenpunkte verworfen. Genau so verhält sich auch der Carbon Aggregator. Die Standardeinstellung MAX_QUEUE_SIZE sollte also regelmäßig überprüft werden.

graphite-queues-and-caches
Carbon Cache als zentrale Stelle

Sehr ähnlich verhält sich Carbon Cache. Er erstellt für jeden Metrikpfad eine eigene Queue. In jeder dieser Queues werden die dazugehörigen Datenpunkte gesammelt, so können später in einer einzigen Schreiboperation mehrere Datenpunkte auf ein Mal geschrieben werden. Das spart I/O, die Daten liegen aber so lange im RAM. Mit der Einstellung CACHE_WRITE_STRATEGY kann eine Strategie ausgewählt werden, mit der Daten geschrieben werden. Ein “Writer Thread” arbeitet diese Queues ab und schreibt die Datenpunkte in die entsprechenden Whisper Dateien. Diese einzelnen Queues können zwar prinzipiell erst mal nicht volllaufen, der gesamte Cache kann es aber. Mit der Option MAX_CACHE_SIZE wird eine Größe festgelegt, die für die Gesamtheit aller Metrik-Queues gilt.

Am besten erzählt der die Geschichte, der sie erlebt hat

Diese Geschichte eines Datenpunkts wird von den Carbon Daemons selbst erzählt. Natürlich in Bildern, mit Graphen. Alle diese Daemons speichern Messwerte über sich selbst. Anhand dieser lässt sich genau verfolgen, wie sich das Setup verhält. Die wichtigsten Metriken dabei sind:

  • Relay
    • metricsReceived – Anzahl der empfangenen Metriken
    • sent – Anzahl der weitergeleiteten Metriken, aufgeschlüsselt pro Ziel
    • relayMaxQueueLength – Aktuelle größe der Queue
    • fullQueueDrops – verworfene Metriken, aufgrund von vollen Queues
  • Aggregator
    • metricsReceived – empfangene Metriken, sollte mit der Anzahl gesendeter Metriken vom Relay übereinstimmen
  • Cache
    • cache.queues – Anzahl der Metrik-Queues
    • cache.size – Summe aller Datenpunkte in allen Metrik-Queues
    • pointsPerUpdate – Anzahl der Datenpunkte die pro Schreiboperation geschrieben werden
    • avgUpdateTime – So lange dauert eine Schreiboperation im Durchschnitt

Das sind natürlich nicht alle, Geschichten brauchen schließlich viel mehr Details. Alle drei Daemons liefern auch Daten über die Ausnutzung von CPU, Speicher und viele weitere Messwerte.

So endet die Reise des Datenpunkts in seinem letzten Ziel: der Whisper Datei. Dort wird er wieder und wieder abgefragt, zu Zwecken der Darstellung. Bis seine Zeit abgelaufen ist und er überschrieben wird, damit endet die Reise dann endgültig.

Blerim Sheqa

Autor: Blerim Sheqa

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

April presented an exciting OSDC, Graphite, Icinga2, NETWAYS, Trainings, Foreman

Beginning with events, our 8th Open Source Datacenter Conference (OSDC) and now the 3rd time in Berlin. Julia reported about the workshops and the general topics for the first and the second conference day while Michael summarized the program of day one and two.
weekly snap

David then described Graphite installation under Debian 8.4 and Michael explained Windows performance counters with NSClient++ and Graphite.

Julia announced the new training concept for Icinga2 and Marius Gebert described why NETWAYS is awesome.

Lastly, Dirk introduced the official Foreman Training and Gunnar provided Avoiding Common Pitfalls with Apply Rules.

Vanessa Muschweck

Autor: Vanessa Muschweck

Vanessa ist unser Head of Finance und somit mit ihrem Team für das Geld, Controlling und Personalverwaltung zuständig. Außerhalb des Büros ist sie sportlich unterwegs und widmet sich neben Tennis hauptsächlich dem professionellem Yoga. Hier macht sie gerade die offizielle Trainer-Ausbildung und kann dann die älter werdende Belegschaft bei NETWAYS ertüchtigen.