Allgemein

Wie sich VSHN mit Hilfe von Soziokratie 3.0 entwickelt

23. Dez 2020

Als wir über 25 VSHNeers (so nennen wir unsere Mitarbeiter) hinauswuchsen, erkannten wir mehr und mehr Aspekte, die uns daran hinderten, die Bedürfnisse unserer Kunden zu erfüllen, innovative neue Produkte zu entwickeln oder unsere einzigartige Mitarbeiterkultur zu erhalten. Je größer wir wurden, desto mehr glaubten wir, dass wir die Organisation weiterentwickeln müssen, um fit für die Zukunft zu bleiben. Hier geht es um die ersten Schritte auf unserer Reise, wie Sociocracy 3.0 uns hilft, unsere Organisationsstruktur weiterzuentwickeln, Menschen zu befähigen und den Kundenservice zu verbessern.

VSHN automatisiert Software Build, Deployment, Provisioning, Backup, Observability, Alerting und Incident Management für Produktionsanwendungen in jeder Cloud mit 24/7-Support. Eine Top-Down, “waterfall” ähnliche hierarchische Organisation hätte uns wahrscheinlich nicht geholfen oder dorthin gebracht. Wir haben immer auf eine sehr agile und demokratische Weise gearbeitet. Außerdem glauben wir, dass Menschen ihr Bestes geben, wenn die Organisation sie effektiv dazu befähigt. Die meisten organisatorischen Veränderungen wurden einfach durch Bauchgefühl und Gespräche untereinander durchgeführt.

Identifizieren von Problembereichen

Wir hatten das Gefühl, dass es nicht mehr skalierbar oder vorteilhaft ist, unsere Tech-Teams nach Technologien zu organisieren (wie OpenShift oder Puppet Managed Services). Diese Trennung funktionierte gut, solange die Kunden den einen oder anderen Technologie-Stack verwendeten. Die heutigen Kunden profitieren von allen Technologien, in denen VSHN Expertise hat. Infolgedessen wurden die Kunden von zwei oder mehr Teams bedient. Um diesem Mangel an Kundenzugehörigkeit etwas entgegenzuwirken, haben wir das Konzept der Service-Manager eingeführt, die die Verantwortung für einen Kunden über mehrere Teams hinweg übernehmen.

  • Letztlich führte dies immer noch dazu, dass die Kunden uneinheitlich bedient wurden. Die Kunden mussten mit zwei oder mehr Teams in Kontakt sein. Beides ist keineswegs effizient oder kundenfreundlich.
  • Die Teams fühlten sich manchmal von den Service Managern kontrolliert und überstimmt. Es führte auch zu einer Art „Kampf“ zwischen den Service Managern, wer zuerst die Hilfe eines Teams erhält.
  • Die Teams konnten auch nicht selbst entscheiden, wie sie einen Kunden am besten bedienen oder ihre Arbeitsmethoden ändern.
  • Das Tagesgeschäft und Kundenprojekte hatten meist Vorrang vor der Produktentwicklung. Das lag daran, dass es keine klare Trennung zwischen diesen Tätigkeitsbereichen gab.
  • Es war oft nicht klar, wen man bezüglich eines bestimmten Produkts oder Kunden fragen musste.
  • Um solche organisatorischen Gegebenheiten zu ändern, fehlten uns die Strukturen, um wichtige Entscheidungen als Unternehmen unter Einbeziehung aller Betroffenen zu treffen. Dies führte dazu, dass einige Entscheidungen von Einzelpersonen getroffen wurden, was sich negativ auf einige der Teams auswirkte. Bauchgefühl war nicht mehr gut genug.

Wie Sie sehen können, war es an der Zeit, Aspekte unserer Organisation zu überdenken, um VSHN fit für die Zukunft zu machen – und um VSHNeers besser in die Lage zu versetzen, ihre Arbeit zu gestalten und auch die Kundenerfahrung zu verbessern.

Wo anfangen

Eine der ersten organisatorischen Änderungen, über die wir nachdachten, war die Organisation unserer Teams nach Kunden und Produkten statt nach Technologiegruppen. Eine Idee, die bereits auf dem VSHNDay 2019 aufkam.

  • Wir wollen mehrere funktionsübergreifende Customer Solution Teams, denen jeweils eine Gruppe von Kunden zugeordnet ist. Das bedeutet, dass ein Kunde ausschließlich von einem Team betreut wird. Mit dem Service Manager als vollwertiges Teammitglied könnte das Team selbstständig über die Arbeitsmethoden, die Arbeitsplanung und die geeignetsten Lösungen für ihre Kunden entscheiden, um den bestmöglichen Service zu bieten.
  • Zusätzlich wollen wir ein oder mehrere Produktteams, die jeweils für eine bestimmte Gruppe von Produkten zuständig sind. Mit dem Product Owner als Teammitglied könnte das Team autonom über das Product Backlog, Arbeitsmethoden und technische Lösungsansätze entscheiden. So könnte sich das Team voll auf seine Produkte konzentrieren, um Features zu entwickeln, Fehler zu beheben und die (Code-)Basis zu pflegen sowie die Solution Teams zu unterstützen, die ihre Produkte nutzen.

Wie machen wir das also? Ende 2019 haben wir beschlossen, dass wir anfangen werden, Muster aus Sociocracy 3.0 zu verwenden, sobald wir etwas sehen, mit dem wir uns weiterentwickeln können. Sociocracy 3.0 – oder kurz S3 – (nicht der Simple Storage Service ), weil es am besten zu dem passt, was wir bereits implizit in den letzten Jahren gemacht haben – hauptsächlich das Prinzip über Gleichwertigkeit und Zustimmung (Consent).

Autonomie von Teams

Unseren Teams einfach die Autonomie geben, das zu tun, was sie für das Beste halten, richtig? Glücklicherweise steckt mehr hinter dieser Geschichte. Wir wollen einem Team Autonomie geben, solange das Team an den übergeordneten Unternehmenszielen ausgerichtet ist, seinen Einflussbereich, seine Aufgaben und seine Grenzen kennt. Oder anders ausgedrückt: Jedes Team muss die Parameter kennen, innerhalb derer es existiert, arbeitet und als Team wachsen kann. Aber das ist noch nicht alles, jede Person oder jedes Team wird auf Situationen stoßen, die sie nicht alleine angehen oder entscheiden können. Wir brauchen Strukturen, die unsere Teams dabei unterstützen, solche Themen zu diskutieren und zu entscheiden.

Wir (und S3) nennen dies Accountability, was Autonomie und Ausrichtung beinhaltet (Autonomy and Alignment).  Um Unternehmensausrichtung und Teamverantwortung zu erreichen, haben wir herausgefunden, dass wir Folgendes brauchen:

  • Für alle transparent sichtbare Ziele, die eine klare “chain of purpose“ aufzeigen: Also begannen wir mit dem Aufbau eines eigenen Alignment Framework , das sich an der Idee von Spotify Rhythm orientiert.
  • Klare Beschreibungen, wofür ein Team verantwortlich ist: Hier kommen S3 Domains und Circles ins Spiel.
  • Sobald wir unsere Einflussbereiche innerhalb des Unternehmens (die Domains) kannten, konnten wir herausfinden, wie sie sich zueinander verhalten oder ineinander enthalten sind. Dies führte uns zu einer klaren Vorstellung davon, wer z. B. die “Accountability“ eines Teams delegiert.

Entscheidungsfindung

Der Beginn der Transformation unserer Organisationsstrukturen verlangte von uns eine Menge Entscheidungen.

  • Wir brauchten einen Weg, um diese Entscheidungen schnell zu treffen und gleichzeitig die betroffenen VSHNeers einzubeziehen.
  • Wir brauchten einen Weg, um Entscheidungen über „brauchbare“ statt „perfekte“ Lösungen zu treffen.

S3 mit den Konzepten und Mustern von ConsentNavigate via Tension und Proposal Forming ist der Weg, den wir wählen, um diese Herausforderung anzugehen. Jetzt könnten wir anfangen, Entscheidungen zu treffen, die für den Moment „gut genug” und „sicher genug” sind, um es bis zur nächsten Überprüfung zu versuchen (“good enough for now, safe enough to try”).

Gut genug klingt vielleicht falsch, oder? Nicht wirklich. In der volatilen, unsicheren, komplexen und mehrdeutigen Welt, in der wir leben, gibt es nie einen perfekten Plan oder eine perfekte Lösung. Etwas, das wir aus der agilen Softwareentwicklung kennen. Wir wollen iterative und kleine Änderungen, schnell lernen, welche Auswirkungen etwas hat und reagieren, indem wir die nächsten Entscheidungen schnell erneut überprüfen und treffen. VSHN hat das eigentlich vom ersten Tag an gemacht – nur dass wir das jetzt für Entscheidungen mit größerer Reichweite machen müssen, die viel mehr VSHNeers und Kunden betreffen.

Der Schlüssel hier ist “Consent” (Zustimmung). Consent bedeutet nicht, dass alle einverstanden sind (oft mit Konsens verwechselt, da es Consent in Deutsch eigentlich nicht gibt), es bedeutet, etwas zu tun, außer es gibt einen Grund, es nicht zu tun, bis wir es wieder überprüfen. Ein Grund könnte sein, wenn es ein Risiko für die Organisation ist oder wenn wir eine lohnende Gelegenheit übersehen würden, den Vorschlag direkt zu verbessern.

Wer entscheidet

Alle in jede Entscheidung einzubeziehen, die wir zu treffen haben, kann die Agilität und Geschwindigkeit behindern. Darüber hinaus würde die Einbindung in zu viele verschiedene Themen auch eine hohe mentale Belastung für alle bedeuten. Der Schlüssel liegt hier darin, die Einflussbereiche der Personen durch Domains zu begrenzen, d. h. klar zu machen, welche Entscheidungen in die Verantwortung welcher Gruppe fallen.

Als Antwort darauf adaptieren wir auch das S3-Konzept der Delegate Circles. Hier senden alle Teams, die betroffen wären, einen Vertreter, um einen „virtuellen“ Kreis zu bilden. Die Delegierten können dann im Namen ihrer Teams Entscheidungen treffen. Hier geht es um Vertrauen – die Mitarbeiter sollen ihrem Delegierten oder anderen Teams oder Gruppen, die für andere Bereiche im Unternehmen zuständig sind, vertrauen können. Im Gegenzug haben sie die Gewissheit, dass sie sich nicht selbst um alles kümmern müssen, was in Ihrem Unternehmen vor sich geht – in dem Wissen, dass sie letztlich immer eine Möglichkeit haben, einen Einwand gegen eine vergangene Entscheidung, eine bestehende Vereinbarung oder eine Aktivität vorzubringen.

Sociocracy 3.0 (S3) in a Nutshell

Sociocracy 3.0 (S3) ist eine soziale Technologie für die Entwicklung von agilen und belastbaren Organisationen jeder Größe, von kleinen Start-ups bis hin zu großen internationalen Organisationen. S3 ist:

  • Flexibel: anpassungsfähige, unabhängige und sich gegenseitig verstärkende Muster, die Sie bei allen Aspekten der Zusammenarbeit unterstützen
  • Prinzipien-basiert: ein kohärenter Weg für das Wachsen organisatorischer Integrität und die Entwicklung einer agilen Denkweise
  • Frei: Sociocracy 3.0 ist frei, und lizenziert unter einer Creative Commons Free Culture license

Erfahre mehr über S3 unter: https://sociocracy30.org/

Wo wir gerade stehen und was die nächsten Schritte sind

Wir haben es geschafft, drei verantwortliche Teams zu bilden. Ein Product Team und zwei Customer Solution Teams. Der erste Rückblick auf diese Teams zeigt, dass unser Ansatz, Teams um Kunden ODER Produkte herum zu bilden, funktioniert. Die Autonomie erlaubt es unseren Teams, den bestmöglichen Weg für ihre Arbeitsweise zu finden und sich als Team zu verbessern.

Wir haben inzwischen für die meisten Bereiche von VSHN klare Domain Descriptions . Das hilft bereits anderen Teams, die nicht direkt von den laufenden Teamveränderungen betroffen sind, indem geklärt wird, wer für was zuständig ist.

Unser Alignment Framework gibt uns bereits Klarheit darüber, was VSHN eigentlich ist, was unsere Ziele sind und wie wir Funktionen und Produkte für die Produktentwicklung sowie Treiber für organisatorische Verbesserungen priorisieren.

Wir haben einen Weg gefunden, das Consent Decision Making (von Tension, Driver über Decision Making und Review von Agreements) auf eine größtenteils asynchrone und schriftliche Weise zu implementieren, was in der heutigen, fast vollständig “remote-work“ geprägten Welt wichtig ist. Wir nennen dies den VSHN Improvement Process.

Als Nebeneffekt werden wir die Begriffe Squad und Chapters los, die aus dem Spotify-„Modell“ stammen (There Is No Spotify Model).

Nächste Schritte

  • Die verbleibenden alten Tech-Teams in das neue Modell der Solution Teams bringen.
  • Unsere Delegate Circles sollen besser funktionieren.
  • Den VSHN Improvement Process vereinfachen, um mehr ein Hilfsmittel zu sein als ein formaler Prozess.
  • Sociocracy 3.0 Interne Lerngruppen und Ausbildungen – wir müssen das S3-Wissen verbreiten.
  • S3 Facilitators, die mit gutem Beispiel vorangehen können. Es ist wichtig, dass VSHNeers andere VSHNeers in ihrem täglichen Arbeitsleben und bei der Entscheidungsfindung anleiten können.

Zusammenfassung – Unsere Erfahrung

Veränderung ist schwer. Aber insgesamt glauben wir bisher, dass wir auf dem richtigen Weg sind. Wir verstehen, warum wir diese Veränderungen vornehmen, gemeinsam als VSHN und unter Beibehaltung eines starken Kundenfokus.

Wir haben gelernt, dass Organisationen in zwei Bereiche unterteilt werden können. Da gibt es das System und da sind die Menschen im System. Die Menschen brauchen das System, um ihren Sinn zu erkennen, um zu wissen, wofür sie verantwortlich sind, was von ihnen erwartet wird und wo die Grenzen und Einschränkungen sind. Ohne dass die Menschen ihren Platz finden und sich dafür engagieren, dass das System funktioniert, kann das System nicht funktionieren. Wir haben uns in den letzten Monaten sehr auf die neuen Strukturen konzentriert. Jetzt müssen wir uns vermehrt darauf konzentrieren, kontinuierlich in die Menschen zu investieren, damit sie sich im System entfalten können.

Was uns an S3 wirklich gefällt, ist der iterative Ansatz. Inkrementelle Veränderungen, Experimentieren und Flexibilität kombiniert mit Consent Entscheidungsfindung – all diese Muster bilden aus unserer Sicht eine bessere Organisation. Auf der anderen Seite können sich Menschen durch inkrementelle Änderungen zwischen der alten und der neuen Welt verlohren fühlen – wir haben gelernt, dass dies ein Risiko darstellt, Menschen zu verwirren und Prozesse, die früher funktionierten, zu gefährden – es ist wichtig, die Balance zu finden zwischen kleinen, inkrementellen Änderungen und nicht den Überblick zu verlieren, wo wir hinwollen.

Was denken Sie darüber? Was sind Ihre Erfahrungen? Wir würden uns freuen, Ihre Geschichten über organisatorische Veränderungen zu hören.

Marco Fretz

Marco ist einer der General Manager von VSHN und Chief Operating Officer.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Interne

Erster Wechsel in der Geschäftsleitung von VSHN, André und Marco

16. Jul 2020

Wie in unserem Blog Post angekündigt, ändern wir unsere Corporate Governance. Ein erster Schritt ist, dass André Keller die Geschäftsleitung verlässt und Marco Fretz mit einem starken Fokus auf die Organisationsentwicklung und das Tagesgeschäft eintritt. Dieser Wechsel erfolgt auf Wunsch von André, da er beschlossen hat, den Schwerpunkt wieder auf die technische Arbeit und das tägliche Kundenservice-Management zu legen und seine Management-Rolle abzugeben. Der Grund dafür:
Bei der Gründung von VSHN im Jahr 2014 wurde das erste Management von VSHN zusammengestellt. VSHN verfolgte immer ein Rollenkonzept, welches die Mitglieder der Geschäftsleitung eingeschlossen hat. Das bedeutet, dass die Mitgliedschaft in der Geschäftsleitung (noch) nicht als Vollzeitbeschäftigung, sondern als zusätzliche Rolle betrachtet wurde. Die Mitglieder der Geschäftsleitung arbeiten hauptsächlich in den Bereichen System Engineering, Finanzen, Sales oder Projekt- und Produktmanagement.
Mit dem raschen Wachstum von VSHN in den letzten Jahren wurden bestimmte Rollen für die VSHNeers immer ausfüllender und mental belastender – insbesondere die Rolle des Managementmitglieds. Dadurch wurde es für VSHNeers schwieriger, sich auf ihre tägliche Arbeit zu konzentrieren – die im Falle von André immer im System Engineering lag und sich um Kundenbedürfnisse in Projekten und im Tagesgeschäft zu kümmern.

„Im Herbst 2018 reiste das Management-Team für eine einwöchige Klausur nach Malta, wo wir uns auf die Herausforderungen konzentrierten, die mit unserem Wachstum einhergingen, sowie auf die Unternehmensstrategie für die kommenden Jahre. Teil dieser Gespräche waren unter anderem die individuellen Ziele der Mitglieder der Geschäftsleitung. Zu diesem Zeitpunkt begann ich zum ersten Mal wirklich über meine eigene Rolle im Unternehmen nachzudenken und darüber, was die Dinge sind, die ich gerne tue und die ich interessant finde und auf welche Aspekte der Arbeit ich am liebsten verzichten würde. Wie man sich vorstellen kann, ist das nicht etwas, das sich in wenigen Stunden leicht herausfinden lässt. Zumindest für mich war es ein mehrmonatiger Prozess.
Am Ende dieses Prozesses wurde mir klar, dass es nicht meine Ambition ist, Teil der Geschäftsleitung zu sein, sondern dass ich mich auf das Tagesgeschäft konzentrieren möchte, indem ich gemeinsam mit unseren Kunden und Partnern an Projekten arbeite.“
– André


„Eines der Dinge, die ich an VSHN liebe, ist die Tatsache, dass jeder die Chance hat, sich über den aktuellen Stellenbeschrieb hinaus weiterzuentwickeln, dass man neue Rollen annehmen und von Rollen zurücktreten kann, die einem nicht mehr gefallen.“
– Marco

Die neue Verwaltungsrat- und Managementstruktur wird einen starken Fokus auf People, Organisationsentwicklung (OrgDev) und die Verfeinerung der vom Verwaltungsrat festgelegten Strategie haben. André freut sich, seine Position in der Geschäftsleitung an Marco Fretz zu übergeben, der die Geschäftsleitung bereits seit einiger Zeit in beratender Funktion unterstützt. Marco begann Anfang 2016 als System Engineer bei VSHN. Von Anfang an interessierte er sich mehr und mehr für organisatorische Themen weit über seine tägliche Arbeit hinaus und trug mit konstruktiven Ideen und Konzepten zum Erfolg von VSHN bei.

„Da ich ein „alter“ VSHNeer bin, all die guten und schlechten Geschichten kenne und eine offene Denkweise habe, bin ich sicher, dass ich eine treibende Kraft für die Veränderungen sein kann, die VSHN braucht, um zukünftige Herausforderungen zu meistern. Gemeinsam können wir die Dinge für uns als VSHNeers wie auch für unsere Kunden verbessern – und weiterhin unsere grossartige familienähnliche Kultur pflegen, die wir so schätzen.
Ich kenne André schon lange vor der Zeit bei VSHN und bin überzeugt, dass diese Entscheidung für André und mich die richtige ist. Wir alle sollten uns auf unsere Ambitionen konzentrieren, um erfolgreich und glücklich zu sein – sowohl privat als auch beruflich“ – Marco

Marco Fretz

Marco ist einer der General Manager von VSHN und Chief Operating Officer.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Event Tech

Open Source Monitoring Conference 2018

14. Nov 2018

Unser Marco Fretz hat die OSMC (Open Source Monitoring Conference) 2018 in Nürnberg besucht und berichtet nachfolgend von seinen Eindrücken.

Die OSMC 2018

Bei der viertägigen OSMC mit rund 300 Besuchern dreht sich alles um Monitoring Tools, Konzepte und die Automatisierung des Monitoring Systems. Natürlich ist Icinga2 sehr stark vertreten – in den Talks, unter den Teilnehmern und Organisatoren. Die Konferenz wird von NETWAYS, der Firma hinter Icinga2, organisiert und findet jährlich im Holiday Inn Hotel in Nürnberg statt.
Am ersten Tag fanden Workshops zu verschiedenen Themen und am vierten Tag ein Hackathon statt, mit Projekten, welche spontan bestimmt wurden. Die englischen und deutschen Talks fanden am zweiten und dritten Tag statt und waren in drei Tracks aufgeteilt. Dank der Agenda (online, vor den Räumen und hinten auf dem Badge) konnte man sich meistens recht leicht für den spannendsten Track entscheiden. Talks, die man verpasst hat, findet man natürlich später online als Video.
Ich habe wieder nur Tag zwei und drei besucht (die Talks). Mit ca. EUR 1500.- für zwei Tage Konferenz, drei Abend-Events und drei Übernachtungen im selben Hotel ist die Konferenz auch preislich sehr attraktiv.
Bekannt ist die OSMC auf jeden Fall auch für das reichhaltige und ausgezeichnete Catering (all-you-can-eat) vom Frühstück bis zu den Abend-Events und den reibungslosen Ablauf – der Hotel und Konferenz Check-In sind in unter einer Minute abgeschlossen. Das hat sich auch dieser Jahr wieder bewahrheitet.
Weitere Eindrücke: #OSMC

Highlights

Für mich war das Wichtigste, neue und bekannte Gesichter zu treffen und der damit verbundene Austausch über die eigene und andere Monitoring Landschaften inkl. deren Probleme und Lösungsansätze sowie natürlich auch der direkte Draht zu NETWAYS / Icinga. Dank dem Talk von @ekeih (scaling Icinga2 …) fanden sich schnell einige Leute, die Icinga2 in einem ähnlichen Setup bzw. Grösse wie wir betreiben.

Prometheus

Spannende Talks zu Prometheus bzw. Konzepten, die auf Prometheus setzen gaben zu spüren, dass Prometheus immer mehr Verbreitung findet, nicht nur in der „Cloud-native“ Welt sondern z.B. auch für HTTP SLA Monitoring (MORITZ TANZER, nic.at), Netzwerk Monitoring (MATTHIAS GALLINGER, ConSol), etc.
Unsere aktuellen Pläne bei VSHN für die Integration von Prometheus in unsere Monitoring Umgebung fanden somit auch hier Bestätigung.

IcingaDB

Ein grosser Flaschenhals bei Icinga2 und Icingaweb2 ist die IDO Datenbank (MySQL / Postgres), dessen Schema noch aus der Nagios und Icinga1 Ära stammt und im Laufe der Zeit ständig verschlimmbessert wurde. Damals schien eine relationale Datenbank für eigentlich volatile Status Informationen wie Service und Host States, etc. Sinn zu machen. In grösseren Setups sind nun aber die Writes von Icinga2 in die DB das bottleneck. Auch leidet die Query Performance von Icingaweb2 in gewissen Konfiguration bei grösseren Setups stark.


Sehr viele Details sind noch nicht bekannt, jedoch kommt Redis für die volatile Status Informationen und eine SQL DB für die historischen Daten zum Einsatz. Eine erste Version läuft bei Icinga bereits testweise und wurde in einer Live Demo vorgestellt. Schön finde ich, dass man wohl das IDO DB und das IcingaDB Modul parallel verwenden kann (übergangsweise), gleiches gilt für das Icingaweb2 Monitoring Modul – Das wird eine Migration stark vereinfachen.
https://twitter.com/jensschanz/status/1059838540748599296

Zum mitnehmen

Einfach auszuprobieren…

OpenAPM

OpenAPM ist kein Tool an sich sondern zeigt auf einfach Weise, welche Tools sich wie miteinander kombinieren lassen, um eine Application Performance Management / Monitoring Landschaft aufzubauen. Einfach hier ausprobieren: https://openapm.io/landscape

Maps

Sicher auch spannend sind die Maps für Icinga2. Man kann jedem Host oder Service Object die Geolocation via custom variable mitgeben, dann werden diese automatisch auf der Map angezeigt und je nach Zoom-Faktor gruppiert: https://github.com/nbuchwitz/icingaweb2-module-map

Rancher Monitoring

Aus dem Talk von @ClaudioKuenzler ein Plugin zum einfachen Überwachen von Rancher2 und Kubernetes: https://github.com/Napsty/check_rancher2

Fazit

Tolle Ideen mitgenommen, neue Leute kennengelernt, viel gegessen (ja der Gin war auch gut (big grin)). Eine super Konferenz, die sich lohnt. Ich geh gerne wieder.

Marco Fretz

Marco ist einer der General Manager von VSHN und Chief Operating Officer.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Event

Icinga Camp Berlin 2018

19. Mrz 2018

Auch dieses Jahr war Marco Fretz wieder am Icinga Camp in Berlin (08.03.2018) und berichtet.
Begonnen hat für mich das #icingacamp bereits am Mittwoch Abend: Nach der Landung in Berlin, einen kurzen Abstecher ins Hotel, dann auf Twitter gelesen, dass ein Tisch in einem Restaurant reserviert sei, 10min zu Fuss und da war ich. Gleich hat man bei Bier und deftigem Essen bekannte Gesichter getroffen und auch gleich weitere Icinga-Fans kennengelernt.
Ausgeschlafen ging es dann am Donnerstag mit Kaffe und Frühstück, gefolgt von der Eröffnung und einem Update zum Icinga-Projekt und der Community von Bernd Erk, los. Sogar unser Icinga Meetup in Zürich am 23.03. wurde erwähnt.

Tech-Talks

Im Talk von Blerim (Icinga), der die fiktive Geschichte des Sysadmins „Dave“ erzählte, ging es darum, wie viele einzelne Tools wie Logging, Alerting, Metrics, Grafiken, etc. erst richtig mächtig werden, wenn man das ganze miteinander kombiniert und integriert. Das hat er vor allem anhand von Icinga2, Elastic Stack und Grafana gezeigt. Mir hat besonders gefallen, wie hilfreich es ist, wenn man Icinga-Events wie „Service Critical“ z. B. direkt über den Graph des Server Loads drüber legt und so Ereignisse mit den Metriken korrelieren kann.
Nicolai Buchwitz widmete seinen Talk dem Virtualisierungstool Proxmox VE (PVE) und dessen Integration in Icinga2, dies einmal mit der automatischen Konfiguration via Icinga Directory Import und anderseits mit einem allround-check-plugin (check_pve) für Icinga, welches dank der mitgelieferten Icinga2 Command-Definitionen die wichtigsten Aspekte einfach von PVE überwachen kann.
Gestärkt vom tollen Mittags-Buffet und nach interessanten Gesprächen mit Icinga-Fans und Icinga-Devs ging es im Vortrag von Michael Medin um sein Projekt NSClient++, dem Monitoring Client für Windows, der, wie es ausschaut, immer mächtiger wird, und übrigens auch unter Linux benutzt werden kann. Für Windows-User waren sehr interessante Neuheiten dabei, wie z. B. das Senden von Event Logs direkt an Elasticsearch oder das automatische Verteilen von Scripts, welche die Funktionalität von NSClient++ erweitern können.
Die Vorträge von Michael Friedrich (Integrationsmöglichkeiten von Icinga2 mit InfluxDB, Graphite, ES, Graylog, Dashboard, etc.) und Thomas Gelf (Icinga Director) waren für mich begrenzt interessant, da die Vorträge sehr ähnlich mit denen von der OSMC im November waren, über die ich ebenfalls einen Blogpost geschrieben hatte. Beim Beispiel, wie man kaputtformatierte Excel Host-Listen via Director importiert, mussten dann doch die meisten lachen – solche Anforderungen solls ja in der Praxis geben.


Der Vortrag zu „Netways Web Services“ fand ich auch spannend. Sebastian Saemann (Netways) erklärte das Setup mit Docker/Mesos/Marathon, welches hinter NWS steckt, und wie sie „Icinga as a Service“ auf dieser Plattform betreiben. Bei NWS kann man sich kinderleicht einen Icinga2-Master inklusive Graphite, Grafana, Director, etc. einrichten oder einen Icinga2-Satelliten konfigurieren, der dann Teil des eigenen Icinga2 Clusters wird – ganz ohne ein einziges CLI command einzugeben.
Im letzten Vortrag plauderte Eric Lippmann (CTO Icinga) etwas aus dem Nähkästchen und ging darauf ein, was sich so bei der Icinga2-Entwicklung tut. Besonders spanned hier die Entwicklung in Richtung IcingaDB, welches das alte, überholte Icinga2 IDO DB Schema ablösen soll. Es wird wohl aber nicht eine eigene DB werden, sonder eher ein neues DB-Schema für MySQL/Postgres plus zusätzlich ein KVP-Store wie Redis für die live-Daten, nur historische Daten sollen zukünftig in die neue SQL DB. Das Ganze steckt aber trotz bereits länger andauernder Entwicklung immer noch in den Kinderschuhen, verständlich, kein einfaches Unterfangen, wenn man sich die technischen Abhängigkeiten aller Komponenten auf die IDO DB genauer anschaut.


Weitere neu Entwicklungen sind die IcingaApp für Android und iOS inklusive Push Notifications, Reporting Features mit anpassbaren Templates und Filtern für Icingaweb2 und ein Notification Manager (NoMa), der ein vereinfachtes verwalten von Notification Contacts und Schedules direkt in Icingaweb2 bringen wird.

Afterevent Beering

Nach dem letzten Vortrag und der Verabschiedung machten sich dann ein Teil der Besucher zusammen mit den Netways/Icinga-Leuten auf die Suche nach einer Bar, die spontan genug Platz für uns hatte. Im Murphy’s Irish Pub eingefunden konnten wir dann noch länger über Icinga2- und Monitoring-Themen diskutieren, bis es dann beim Bier und Essen immer etwas weniger technisch wurde.

Fazit

Trotz ein paar grösserer Probleme mit meinen Rückflügen von Berlin, ein sehr lohnenswerter Event und Ausflug nach Berlin. Man knüpft neue Kontakt zu Icinga2-Entwickler und anderen Benutzern und spricht direkt über aktuelle Probleme, Verbesserungen und neue Ideen.

Marco Fretz

Marco ist einer der General Manager von VSHN und Chief Operating Officer.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Event

OpenSource Monitoring Konferenz

27. Nov 2017

Für alle, die nicht dabei waren

Mit über 250 Teilnehmenden fand dieses Jahr die 12. OpenSource Monitoring Conference (kurz OSMC) in Nürnberg statt. Nicht jeder hat Zeit, das Budget oder Lust solche Konferenzen zu besuchen. Was ist die OSMC eigentlich und was war für mich persönlich am spannendsten? Dies erfahrt ihr in diesem Blogpost.
Es hat sich gelohnt und ich kann jedem, der im Bereich Monitoring arbeitet oder daran interessiert ist, diese Konferenz wärmstens empfehlen.

Was ist die OSMC

Bei der OSMC dreht sich alles um Monitoring und heutzutage natürlich auch um die Automatisierung des Monitoring Systems. Die Konferenz wird von NETWAYS, der Firma hinter Icinga2, organisiert. Mit 4 Tagen ist die Konferenz grundsätzlich nicht in die Länge gezogen, bietet aber dennoch genügend Platz viele interessante Talks und genügend Pausen für Networking unterzubringen. Die eigentlichen Talks fanden am zweiten und dritten Tag statt. Tag eins war in vier Workshops aufgeteilt und an Tag vier fand ein Hackathon statt, mit Themen, welche spontan bestimmt wurden. Ich habe nur Tag zwei und drei besucht (die Vorträge), kann darum zu den Workshops und dem Hackathon nicht viel sagen.  Mit EUR 899.- für Tag 2 und 3, ohne Unterkunft ist die Konferenz nicht gerade günstig, aber für das gebotene Programm und die professionelle Organisation ein durchaus fairer Preis. Weitere, etwas teurere Pakete, enthalten auch die Unterkunft im Hotel und / oder den Workshop- und Hackathon-Tag. Ich hatte mich aufgrund privater Planung für ein anderes Hotel in fünf Gehminuten Entfernung entschieden.

Location, Organisation und Ablauf

Man hätte sich eigentlich keine bessere Location als das Holiday Inn Nürnberg vorstellen können: viele Konferenzräume, genügend Platz für Small Talk und Networking in den Pausen und natürlich mit ausgezeichneter und reichlicher Verpflegung zum Frühstück, in den Pausen und am Mittag.
NETWAYS hat tolle Arbeit mit der Organisation und Durchführung der Konferenz geleistet. Der Empfang war herzlich und die Damen und Herren von NETWAYS waren bei Fragen immer leicht auffindbar. Der (technische) Smalltalk mit den Entwicklern von Icinga2 kam vielen Besuchern sehr gelegen, verständlich, wenn man schon mal direkt an der Quelle ist.
Die Talks wurden am 2. Tag in drei Tracks aufgeteilt, am 3. Tag in zwei Tracks. Das heisst, man konnte bzw. musste sich jeweils für einen der zwei oder drei parallel stattfindenden Talks entscheiden. Dies war dank des klaren Programms mit Uhrzeit, Titel, Sprecher und Sprache immer recht einfach. Mir ist es in den zwei Tagen nur zwei Mal passiert, dass ich das Gefühl hatte, besser den anderen Talk gewählt zu haben – ein Verbesserungsvorschlag meinerseits wäre hier, eine Art „Skill-Level“ im Programm zu vermerken. Zum Glück werden aber alle Talks professionell in hoher Qualität aufgezeichnet und später veröffentlicht – das Aufzeichnen als Video finde ich persönlich sehr viel sinnvoller als Slides zu teilen, da diese alleine meistens kaum den Inhalt eines Talks wiedergeben können.
Am Abend des zweiten Tages konnte man beim Socialevent im Club nachtkind, ca. 10 Minuten zu Fuss vom Holiday Inn, bei reichlich Bier, Wein, Drinks und super Essen auch mal etwas weniger ernsthaft und technisch diskutieren und feiern – eine gelungene Abwechslung zwischen den Konferenztagen. Für die Teilnehmer des Hackathon gab es auch am 3. Tag einen ähnlichen Abendanlass.

Es gibt nicht nur Icinga

Auch wenn NETWAYS die Konferenz organisiert, drehte sich absolut nicht alles nur um Icinga2 und auch nicht nur um Produkte und deren Implementation. So wurde z. B. in den Talks von Markus Thiel und Marianne Spiller vor allem die Erfahrungen, Theorie, best-practices und Konzepte zum „perfekten Monitoring“ aufgezeigt – sehr hilfreich, um auch einmal die eigene Monitoring Landschaft mit etwas Abstand zu hinterfragen.


In mehreren Talks wurde auch gezeigt, was Sensu so alles kann und warum das Konzept von Sensu durchaus Sinn macht in verteilten und hoch dynamischen Setups (Auto-Scaling, Docker, etc.). Sehr spannend bei Sensu ist, dass man z. B. mit Puppet oder Ansible die ganze Check-Konfiguration auf dem Agenten macht und nicht auf Sachen wie Exported-Resources (Puppet) angewiesen ist. Mir persönlich fehlt bei Sensu jedoch immer noch etwas die „Gesamtlösung“ (UI mit Mandantenfähigkeit / Rollen, Downtimes, Graphen direkt beim Service, usw.). Die Community, die alternativen WebUIs und Tools rund um Sensu scheinen aber zuzunehmen und das Potenzial von Sensu ist gross, gerade da es auf RabbitMQ für den Datenaustausch und als Message-Bus aufbaut und das Konzept dadurch sehr einfach erscheint.
Einer der besten Vorträge war für mich der von James Shubin mit „Next Generation Config Mgmt“ über mgmtconfig. James hat, neben seiner Aufgabe das Publikum zum ersten Vortag wachzuritteln (mit einer kleinen Feuer-Show und Musik), gezeigt, dass ein modernes Konfiguration-Management (in golang und auf Basis von etcd) auch eine Art Monitoring sein kann und direkt auf Events reagiert, statt nur periodisch und in langsamen Durchläufen Änderungen forciert. Dank einer gewissen Kompatibilität zu Puppet und der wachsenden Community ist dies sicherlich ein Projekt, welches wir bei VSHN im Auge behalten werden.


Natürlich gab es auch Vorträge zu Prometheus z. B. wie man zusammen mit Grafana, MySQL besser montioren kann von Julien Pivotto.

Trotzdem kommt man als Icinga Fan nicht zu kurz

Der Vortrag „Current State of Icinga“ war (wie auch schon am Icinga Camp und am Icinga Meetup Zurich) sehr informativ. Mir gefällt die Richtung der Icinga2 Entwicklung sehr, denn man erfindet nicht das Rad neu, stattdessen wird viel investiert um mit Icinga2 im Zusammenspiel mit Elasticsearch, Kibana, Logstash, InfluxDB, Grafana, Graphite, usw. integrierte Lösungen zu ermöglichen.
Auch in Icinga2 selbst und Icingaweb2 tut sich viel:

  • Die neue IcingaDB wird zwar erst konzipiert (die Umsetzung ist für nächstes Jahr geplant), trotzdem eine sehr wünschenswerte Entwicklung, ist das aktuelle IDO-DB Schema doch sehr veraltet und kämpft mit Performance Problemen.
  • Mit Icinga2 Release 2.8 wurde der CA-Proxy eingeführt, ein echt wichtiges Feature, mit dem Agents nun auch über einen Satelliten Zertifikate anfragen (CSR) können – bis anhin ging das nur direkt über den CA Host (meistens Master-Zone), was in verteilten Setups mit abgelegenen Netzwerk-Segmenten immer schwierig ist.
  • Icingaweb2 2.5 bring ein optisch überarbeitetes GUI.

Der Director  (Modul für Icingaweb2) wird langsam aber sicher zum Mittelpunkt der automatischen  Konfiguration von Icinga2. Mit Import-Modulen für die PuppetDB, LDAP / MS AD, CSV, SQL, VMWare und vielen mehr lässt sich die Konfiguration von Icinga2 Hosts, Services, etc. auch ohne Konfigurations-Management (Puppet, Ansible, u.Ä.) automatisieren und die Konfiguration dieser Imports und Syncs wird immer übersichtlicher und einfacher.
https://twitter.com/dnsmichi/status/933666420277334017
Mehrere Vorträge drehten sich um die automatische Konfiguration von Icinga2 (Puppet / Ansible) oder um Projekte mit Icinga, dessen Integration und damit gemacht Erfahrungen.

Fazit

Es ist mir natürlich nicht möglich, die 28 Vorträge im Rahmen dieses Blogposts zusammen zufassen, darum empfehle ich allen sich mit #monitoringlove dringend sich die Talks später online anzusehen und natürlich die nächste OSMC zu besuchen – dann aber bitte auch (Wissens-)Hunger mitbringen.

Marco Fretz

Marco ist einer der General Manager von VSHN und Chief Operating Officer.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Tech

Distributed Monitoring mit Icinga2 und Puppet

13. Jul 2017

Wir bei VSHN betreiben Applikationen auf Servern und Container Plattformen für Kunden mit verschiedensten Anforderungen. Dabei bilden neben dem Konfigurationsmanagement und der wöchentlichen Maintenance auch die täglichen Backups und natürlich das Monitoring die zentralen Punkte des proaktiven DevOps Betriebs. Bei aktuell über 600 managed Servern mit mehr als 30’000 Services wäre die manuelle Konfiguration sowie das Tuning des Monitorings und der Umsysteme wie InfluxDB, Grafana, etc. recht mühsam – darum haben wir dies komplett automatisiert.

In diesem Blog-Post zeigen wir, wie wir dies bewerkstelligen und wohin die Monitoring-Reise bei VSHN geht.

Architektur

Icinga2 ermöglicht ein komplett verteiltes Monitoring Setup, in dem auf jedem zu überwachenden System eine Icinga2 Instanz läuft. Jeder Client verbindet dann, meistens mit einer ausgehenden TCP Verbindung, verschlüsselt und über x509 authentifiziert, zur Master- oder der überliegenden Satelliten-Zone. Dies ist wichtig, da wir oft Systeme im Enterprise Umfeld betreiben, bei denen wir dann meistens auf einem Jumphost oder dediziert einen Satelliten betreiben. Anschliessend benötigt ausschliesslich dieser eine Verbindung ins Internet zu unserem Monitoring Master.
Des Weiteren kann so ein Server tagelang offline sein und trotzdem haben wir rückwirkend die komplette History und die Performance Daten (man kann auch rückwirkend Performance Daten in die InfluxDB schreiben), weil jede Icinga Instanz lokal ein Replay Log speichert und dieses anschliessend wieder an die überliegende Zone senden kann.
Eine Zone kann auch aus mehreren Icinga2 Instanzen (Servern) bestehen, um die Last zu verteilen und die Verfügbarkeit zu erhöhen.
Für die Authentifizierung und Autorisierung der VSHN- und Kunden-Benutzer ist Icingaweb2 ausserdem an unser zentrales LDAP angebunden. Eine Integration mit Grafana ermöglicht die Vorschau von Performance Data Grafiken direkt in Icingaweb2. Grafana greift auf InfluxDB zu, die wiederum von der Icinga2 Master Instanz mit Performance Daten befüllt wird.

Automatische Konfiguration

Alle unsere Server werden vollständig automatisiert mit Puppet konfiguriert. Dabei weisen wir via Hiera den Servern Rollen zu. Eine Rolle besteht wiederum aus Puppet Profilen (VSHN eigene Puppet Module, die meist auf einem Puppet Base Modul aufbauen). Das Profil steuert immer auch Backup, Firewall und Monitoring. So ist sichergestellt, dass jeder Server eine korrekte Backup-Konfiguration und die richtigen Firewall Rules hat und eben auch automatisch im Monitoring eingerichtet wird. Das heisst, es ist ausgeschlossen, dass ein managed Server nicht im Monitoring eingerichtet ist.

Cluster Konfiguration

Ein Icinga2 Cluster wird immer mittels Zonen und Endpoints konfiguriert. Zonen können mehrere Endpoints (Server mit Icinga2 Instanz) enthalten.

Die manuelle Konfiguration dazu würde vereinfacht so aussehen:

# zones
object Zone "master" {
  endpoints = [ "master1.vagrant.dev" ]
}
object Zone "sat1.vagrant.dev" {
  parent = "master"
  endpoints = [ "sat1.vagrant.dev" ]
}
...
object Zone "clientB.vagrant.dev" {
  parent = "sat1.vagrant.dev"
  endpoints = [ "clientB.vagrant.dev" ]
}
# endpoints
object Endpoint "master1.vagrant.dev" {
  host = "192.168.33.101"
}
object Endpoint "sat1.vagrant.dev" {
  host = "192.168.12.102"
}
...
object Endpoint "clientB.vagrant.dev" {
  host = "192.168.12.104"
}

Das muss dann noch auf allen beteiligten Server so gemacht werden. Ausserdem müssen neben der Icinga2 Grund- und Feature-Konfiguration entweder die Icinga2 eigene x509 PKI konfiguriert und verwendet oder die Zertifikate auf andere Weise ausgestellt und verteilt werden. Details zur manuellen Konfiguration sind hier zu finden: https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/
Bei uns wird das natürlich alles via Puppet gemacht. In der Regel reicht folgende Konfiguration aus Hiera (Beispiel für einen Client, der zu einem Satelliten verbindet):
Beispiel Client hinter Satellite

profile_icinga2::parent_zone: 'sat1.vagrant.dev'
profile_icinga2::parent_endpoints:
  'sat1.vagrant.dev':
    host: '192.168.12.102'
 profile_icinga2 kümmert sich dann um alles, inklusive der Zonen / Endpoint Konfiguration und konfiguriert die sowieso vorhanden Zertifikate der PuppetCA für die Icinga2 API. Das offizielle Puppet Modul für Icinga2 gibt es hier: https://github.com/Icinga/puppet-icinga2

Host und Service Checks – Konfigurations-Flow

1. Puppet Run auf einem Server inkludiert profile_icinga2 und Service Profile (z.B. profile_mariadb), Beispiel Hieradata:

---
classes:
 - profile_icinga2
 - profile_mariadb
profile_mariadb::manage_monitoring: true # default

2. Icinga2 Profil exportiert

  • Host Object
  • MariaDB Service Check

3. Puppet run auf Monitoring Master
4. Im selben Puppet run auf dem Monitoring Master werden alle Host Objects und Service Objects gesammelt und in Icinga2 angelegt
5. Die Hosts und Services werden im Config Sync Verzeichnis (zones.d) der jeweiligen Client Zone von Puppet angelegt
6. Icinga2 config check wird von Puppet durchgeführt und Icinga2 reloaded
7. Icinga2 synchronisiert die Config via Top-Down-ConfigSync auf alle Satelliten und Clients

  • Jede Satellite und Client Instanz bekommt dabei nur die Config, die ihn auch wirklich betrifft
  • Jede Instanz validiert und aktiviert die Config

8. Icinga2 Satelliten syncen die Configs auf ihre Clients
9. Check ist im Monitoring:

Die Nachteile von Exported Resources

Puppet ist unser primäres Konfigurationsmanagement und Automatisierungs-Werkzeug. Allerdings ist bei der Verwendung von Exported Resources immer Vorsicht geboten.

  • Verlust der PuppetDB Daten führt zum Wegräumen aller Hosts und Services im Monitoring, was sich zwar wieder – nachdem jeder Server wieder einen Puppet run gemacht hat – von selbst „heilt“. Trotzdem unschön.
  • Die ganze Sache ist sehr träge, da jede Änderung einen Puppet run auf dem Server (Icinga2 Client) und auf dem Icinga2 Master benötigt, bevor die Änderungen wirksam sind.
  • Der Puppet run auf dem Monitoring Master sammelt tausende Zone-, Endpoint-, Host- und zehntausende Service-Objects Resources zusammen und ergibt somit einen Puppet run, der locker länger als 20-30 Minuten dauert. Das System wird somit noch träger.

Mögliche Lösungen

Wir wollen in Zukunft auf das Einsammeln von Exported Resources verzichten und Icinga2 direkt mit den Daten aus der PuppetDB konfigurieren. Warum? Weil ein Puppet Run auf fast allen Servern im 1-2 Minuten-Bereich oder weniger liegt, der Puppet Run auf dem Monitoring Master jedoch das Problem ist.
Es gibt auch bereits eine Lösung: Icinga2 Director mit PuppetDB Anbindung 

Dabei würden die Server weiterhin Host und Service Objects via Puppet exportieren, jedoch sammelt ein Import / Sync Job (3) des Directors die Objekte direkt aus der PuppetDB zusammen, filtert und konfiguriert daraus Icinga2 Objekte.

Resultat

Nur noch ein schneller Puppet Run auf den eigentlich betroffenen Server, Änderungen sind innert 1-2 Minuten in Icinga2 aktiv. Der Puppet Run auf dem Monitoring Master gerät in der Hintergrund und ist maximal noch für die Zonen Konfiguration und PKI zuständig, welche im Vergleich zu Service Checks und dem damit verbundenen Tuning eher statisch ist.

Fazit

Verglichen mit der manuellen Konfiguration von Hosts und Services in einem Monitoring System oder der für uns fast komplett unbrauchbaren Auto-Discovery Funktionen anderer Systeme, haben wir mit top Open Source Software eine Lösung geschaffen, die unsere Anforderungen erfüllt, sich komplett in unsere DevOps Arbeitsweise integriert und uns somit den proaktiven Betrieb für unsere Kunden ermöglicht sowie extrem vereinfacht. Es gibt aber an zahlreichen Punkten Verbesserungspotential und uns wird es darum sicher nie langweilig.
Mehr zu Distributed Monitoring mit Icinga2: https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/
Dies wird sicher nicht der letzte Blog Post zu Icinga2, Icinga2 Director, Monitoring usw. gewesen sein.

Marco Fretz

Marco ist einer der General Manager von VSHN und Chief Operating Officer.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Event

Icinga Camp Berlin 2017 – VSHN war dabei!

12. Mrz 2017

Am 07. März 2017 fand das jährliche Icinga Camp in Berlin statt. Marco Fretz war dabei und berichtet.
Mit der Kalkscheune als Event Location in Berlin Mitte haben die Organisatoren eine gute Wahl getroffen. Die Kombination aus zeitgemässer technischer Ausstattung und dem historischen Charme einer alten Fabrikstätte war die ideale Kulisse für das Icinga Camp. Das leckere Chilli con carne Mittagsbuffet trug ebenfalls zur guten Stimmung der Teilnehmer bei. Dank der Aktion „Eine Flasche Gin geschenkt, wer das letzte Ticket kauft“ war die Konferenz dann auch ausverkauft. Trotzdem hatten alle Teilnehmer angenehm Platz in der Galerie der Kalkscheune.

Ein Hauptargument für das Icinga Camp ist für mich, dass ein Grossteil des Core Entwicklerteams und der Community Manager anwesend sind. Man kann persönlich über Ideen und technische Fragen diskutieren – wofür sich das Icinga Team auch offiziell anbot und sich mit Icinga2 Bekleidung zu erkennen gab.

Stand der Dinge

Bernd Erk (CEO von Netways) eröffnete die Konferenz mit einem Überblick und Status Update des Icinga Projekts. Eine erstaunliche Aussage war hier, dass die Icinga Community eigentlich nur sehr begrenzt weiss, wer Icinga überhaupt und für welche Zwecke einsetzt. Obwohl es für das Einsenden von Referenzen ein Online Formular gibt, scheint dies wenig genutzt. Deshalb ist unsere Bitte als grosse Icinga Fans: Bitte meldet euer Projekt / Firma als Referenz, die Icinga Community wird sich sehr darüber freuen.
Natürlich waren vor allem die technischen News spannend und teils auch überraschend. Noch vor einigen Wochen habe ich mich wieder einmal über das doch recht altmodische DB Schema vom Icinga2 IDO Backend gewundert und jetzt die Info „Wir sind dabei das Datastore Backend von Icinga2 zu ersetzen“. Obwohl noch keine genauen technischen Infos bekannt geben wurden, geht es hauptsächlich Richtung Skalierbarkeit, Performance und Vereinfachung.
Eine weitere erfreuliche Neuigkeit war, dass das komplett neu geschriebene Puppet Modul für Icinga2 nun einen für den produktiven Einsatz tauglichen Stand erreicht hat. Auch sind Play- und Cookbooks für Ansible und Chef verfügbar. Natürlich alles auf Github mit dem Ziel, die Community an der Weiterentwicklung mit einzubeziehen.
Im Bereich der Anbindung an andere Systeme gab Michael Friedrich von Netways (aka @dnsmichi) in einem eigenen Talk einen Überblick über die Integration und Anbindung von Icinga an andere Systeme. Besonders ins Auge fiel hier die Anbindung an Elasticsearch via Icingabeat. Nach der bereits länger verfügbaren Unterstützung für Graylog via GELF sicher eine willkommene Variante für alle, die bereits Elasticsearch und Kibana einsetzen. Michael erwähnte hier mehrmals, dass das Feedback auf Github oder per Mail, sowie Anwendungsbeispiele hier sehr willkommen sind. Sehr interessant ist die Kombination von InfluxDB und Grafana für Performance Daten, wie wir es bei VSHN nun schon länger einsetzen. Für die Einbindung von Grafana in Icinga Web stehen aktuell zwei Module zur Verfügung, eines davon aus der Schmiede von VSHN.

Wie überwacht man richtig?

Einer der kurzweiligsten Talks war definitiv „How to write checks that don’t suck“ von Mattis Haase. Anhand eines Publikum-Experiments hat Mattis hier erfolgreich gezeigt, wie ein überlegt umgesetzter Check das Leben eines SysOps oder vor allem OnCall Engineers um 3 Uhr morgens erleichtern kann. Die Kernaussagen waren dabei:

  • Keine nutzlosen Informationen anzeigen, Sachen die funktionieren interessieren nicht – ich will wissen, was NICHT funktioniert und warum ich geweckt wurde.
  • Menschenlesbare Sprache im Text des Checks verwenden, das Monitoring System soll dem Operator Arbeit abnehmen, d. h. somit für ihn arbeiten und nur nützliche Infos liefern.

Mit „Know your Hardware“ startet Werner Fischer von Thomas Krenn seinen Talk. Teilnehmer, die mit der Hardware Überwachung von Servern zu tun haben, konnten viele nützliche Tipps mitnehmen. Ausserdem stellt Thomas Krenn tolle fertige Check Plugins für IPMI und weitere Arten der Hardware Überwachung via Icinga zur Verfügung.

Frontends, Icinga Web 2 und Director

Eric Lippmann, CTO von Icinga, und Thomas Gelf (Lead Architect) haben in ihren zwei Talks aufgezeigt, wie mächtig Icinga Web 2 eigentlich ist. Jeder mit minimalen PHP und HTML Kenntnissen hat die Möglichkeit, Module für Icinga Web und das Icinga CLI zu schreiben. Das Beispiel Modul in der Präsentation konnte hier mit wenigen Code Zeilen bereits verschiedene Geschmacksrichtungen von Gin auflisten (smile).
In der aktuellen Version des Icinga Directors stehen neue, für den professionellen Einsatz taugliche Möglichkeiten im Bereich des Config Managements für Icinga zur Verfügung: Von der kompletten manuellen Administration via WebGUI von Host, Services und Templates bis hin zur automatischen Generierung der Konfiguration aus einer CMDB oder z. B. der PuppetDB bietet der Icinga Director nun fast alles, was das Automatisierungs-Herz begehrt. Die Berechtigungs-Verwaltung für die Mandantenfähigkeit des Directors sei aktuell in Arbeit.
Sven Nierlein stellte uns mit Thruk eine Alternative zu Icinga Web genauer vor. Viele Features und grosse Möglichkeiten im Bereich Reporting verdrängen dabei den Eindruck, dass das Frontend zumindest noch ein bisschen nach Nagios aussieht. Auf jeden Fall eine echte Alternative, vor allem wenn man noch Nagios, Icinga1, Shinken oder andere Systeme, die auf Nagios basieren anbinden will.

Die etwas anderen Checks

Mit Alyvix stellte Francesco Melchiori von Würth Phoenix ein End User Experience Monitoring auf Basis von grafischen Checks vor. Alyvix kann neben grafischen Bereichen und OCR regex Matching im Bild einer Applikation sogar Citrix „Video Streams“ anhand von Veränderungen in der Frame-Rate erkennen. Die Integration (aktuell leider nur unter Windows) ist mit NSClient++ und einer Kombination aus aktiven und passiven Checks gelöst.
Im „Monitoring the Monitoring of (Siemens) Trains“ zeigte uns Eduard Gueldner, wie man mittels der mächtigen Icinga DSL in reinen Dummy-Checks Daten auswertet und dabei auch mit tausenden von Checks praktisch keine Rechen-Ressourcen verschwendet – dies vor allem dann, wenn man keinen Einfluss darauf hat, wie man die Daten bekommt oder keine eigenen Check Scrips auf Fremdsysteme ständig anpassen möchte.

Fazit

Alles in allem ein angenehmer und interessanter Ausflug nach Berlin, von dem ich viele neue Ideen für Verbesserungen und zukünftige Projekte mitnehmen konnte. Wir sind nächstes Jahr sicher wieder dabei. Ebenfalls planen wir als VSHN in absehbarer Zeit ein Icinga Meetup in Zürich abzuhalten, Infos folgen.
Übrigens: Ja, ein Teilnehmer erhielt während des Eröffnungs-Talks wirklich eine Flasche Gin. Es scheint, als gehöre Gin einfach zur Icinga Community.

Links

https://twitter.com/search?q=%23IcingaCamp
Die Slides und Videos sollten bald im Icinga Blog veröffentlicht werden: https://www.icinga.com/blog/ 

Marco Fretz

Marco ist einer der General Manager von VSHN und Chief Operating Officer.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt