Vergangene Woche berichteten wir hier über unsere Eindrücke der diesjährigen Open Source Monitoring Conference Ende November 2017 in Nürnberg. In Teil zwei dieser Blogserie möchten wir diese Eindrücke aufgreifen und auf die derzeitigen Anforderungen an Monitoring-Umgebungen und deren Architekturdesign eingehen.

Diesjährige Vorträge

Schaut man sich die Liste der diesjährigen Vorträge an, fällt es nicht schwer mögliche Kernthemen auszumachen. Hier ein kleiner Auszug daraus:

– Monitoring Challenges in a World of Automation

– Automatisiertes und verteiltes Monitoring in einer CI Umgebungen

– Ops and dev stories: Integrate everything into your monitoring stack

– Automated Monitoring in heterogeneous environments

– Icinga2 + Director, flexible Thresholds with Ansible

– Montioring MySQL with Prometheus and Grafana

– Monitoring with Sensu – it‘s the sensuable thing to do

– Monitoring – dos and dont‘s

Schnell ist zu erkennen, dass die Themen Automation und Integration zu immer wichtigeren Punkten werden. Veränderungen im Design der IT-Landschaft und die Notwendigkeit Systeme und Applikationen dynamisch skalieren zu können, stellen System-Architekten und Administratoren vor neue Herausforderungen. Tool-seitig gegebene Automations- und Integrationsmöglichkeiten bringen Flexibilität. Erreichen lässt sich dies beispielsweise (nicht nur, aber auch) durch Auftrennen monolithischer Lösungen in separate Layer. Zudem werden neben den Monitoring-Dauerbrennern Icinga2, Zabbix, OpenNMS und CheckMK für bestimmte Anwendungsfälle neuartige Monitoring-Lösungen, wie Prometheus oder Sensu, in Betracht gezogen.

Ein Fehler jedoch, der hierbei häufig gemacht wird, ist naiv auf neue Technologien umzustellen, in der Hoffnung somit die genannte Flexibilität zu erlangen. Oft wird in neuen Lösung ein Allheilmittel gesehen, nur weil sie neu sind. Wichtig ist hierbei aber: Es muss je Fall abgewogen und entschieden werden, welcher Tool-Stack auf die vorzufindende IT-Umgebung und der dort gelebten Prozesse passt. Genau hier liegt eben auch der Knackpunkt – ob KMU oder großer weltweit agierender Konzern, ob statische IT-Umgebung on-premises oder eine IT-Landschaft mit hoher Fluktuation an Soft- und Hardware / VMs / Containern in einer cloud-artigen Infrastruktur. Sich für eine Lösung zu entscheiden und anschließend versuchen diese über seine IT-Landschaft und -Prozesse zu stülpen kann funktionieren, benötigt meist jedoch einige Anpassungen. Das birgt Nachteile hinsichtlich Zeit, Kosten und ggf. Updatefähigkeit. Besser ist, genau umgekehrt zu agieren und zunächst nicht in konkreten Tools zu denken. Fragen, die man sich vor dem Einführen neuer Lösungen stellen sollte, könnten sein:

Wie werden die IT-Prozesse gelebt?

Was für eine Art IT-Landschaft ist vorzufinden?

Welche konkreten Anforderungen gibt es?

Was Funktionen sollen existieren?

Das passende Tool

Bei der Tool-Findung sollte also weniger in existierenden Lösungen, vielmehr in benötigten Funktionen gedacht werden.

Wurde ein passendes Tool gefunden, passiert es, dass sich Unternehmen, Infrastrukturen, Prozesse oder Personal verändern – oft nur langsam, aber stetig. Bestehende Lösungen müssen hier mitziehen und sich anpassen können. Viel einfacher fällt das, wenn Lösungen im Einsatz sind, die durch Ihre Architektur entsprechend flexibel sind und standardisierte Schnittstellen verwenden.
Sind vor allem in KMUs All-in-One-Lösungen sehr beliebt, da sie schnell installiert sind und „von allem Etwas“ bieten (Monitoring, Thresholding, Alarming, Graphing, Archive, Reporting, Analyse, Trends), so ist ein wahrzunehmender Trend zweifelsohne die Umstellung auf Lösungen, die oft nur für genau einen Zweck verwendet werden, diesen optimal beherrschen und sich leichter in bestehende Tool-Stacks integrieren lassen. Verbunden wird anschließend eine Vielzahl von Lösungen beispielsweise via auf Webservices basierender RESTful APIs. Auf den ersten Eindruck steigt dadurch der Aufwand und die Komplexität. Auf den zweiten Blick birgt dieser Ansatz jedoch viele entscheidende Vorteile. Sind Lösungen im Einsatz, die den Microservices-Ansatz verfolgen und reichlich Integrations- und Automatisierungsmöglichkeiten bieten, fällt es später deutlich leichter einzelne Lösungen zu ersetzen. Dies reduziert die Abhängigkeit zu einer bestimmten Lösung, sowie zu dessen Hersteller und erspart oft aufwändige Anpassungen, da für den konkret benötigten Zweck die passende Lösung eingesetzt wird. Auf Dauer lässt sich so die Anzahl von großen Migrationsprojekten reduzieren, wodurch Zeit und Geld eingespart werden kann. Ein weiterer Treiber zur Verfolgung dieses Ansatzes ist die Möglichkeit stets innovativ zu sein. Gibt es einen neuen Vorreiter in einem Sektor, kann ohne große Anpassungen an dem kompletten Tool-Stack genau dieser eine Teil ausgetauscht werden.

Steht man vor der Herausforderung eine neue Monitoring-Lösung oder eine andere Lösung im Orbit seiner Monitoring-Tool-Landschaft einzuführen oder zu ersetzen, sind all das Gründe, die für den Aufbau eines solch modularen Tool-Stacks sprechen, insofern die Bedingungen hinsichtlich der eigenen IT-Infrastruktur und -Prozesse passen.

In dem Monitoring-Router Sensu sehen wir eine optimale Möglichkeit, all diese Vorteile zu erlangen. Sensu bietet durch seine Vielzahl an Integrationen und seiner Schnittstellen die gewünschte Flexibilität, um den Grundstein für einen auf die jeweilige IT-Landschaft maßgeschneiderten Tool-Stack zu legen. Der modulare Aufbau bietet zudem die Möglichkeit horizontal und je nach Last zu skalieren. Detaillierte Informationen zu Sensu und dessen Funktionalitäten können hier nachgelesen werden. Gerne verweisen wir in diesem Zuge auch auf unseren Blogartikel vom Sensu Summit 2017 sowie der zweiteiligen Blogserie über „Software in Cloud-Infrastrukturen“ Teil 1 und Teil 2.

Wer sich jetzt noch selber einen Eindruck von den Vorträgen der OSMC machen möchte, kann dies unter den folgenden Links tun. Inzwischen sind auf dem YouTube Kanal der Netways GmbH auch alle Talks als Video nachzuschauen:

OSMC Vorträge

YouTube Kanal der Netways GmbH

Open Source Monitoring Studie