© Ekaphon maneechot/Shutterstock.com
Wie ändert sich das Monitoring mit der Microservices-Architektur?

Microservices brauchen ein neues Monitoring


Verteilte Systeme zu betreiben und zu überwachen, kann sehr schwierig sein. Es kommen neue Anforderungen auf den Betrieb und die Entwickler zu. Während das Monitoring bei einer monolithischen Anwendung noch recht einfach und übersichtlich ist, gibt es beim Microservices-Ansatz mehrere Systeme, die überwacht werden müssen. Welche Herausforderungen müssen bei einem Umstieg angegangen werden?

Bei Microservices-Ansätzen werden kleine Services feingranular nach fachlichen Domänen geschnitten und können somit von verschiedenen Teams unabhängig entwickelt, veröffentlicht und betrieben werden. Am Ende bildet ein Netz von Microservices ein Gesamtsystem. Dieser Ansatz hat sehr viele Vorteile, bringt aber auch neue Herausforderungen beim Thema Monitoring für die Entwickler, den Betrieb und den Fachbereich mit.

Entwickler sind an Anwendungsmetriken interessiert. Sie möchten nachvollziehen können, wie sich die Anwendung im laufenden Betrieb verhält. Wie ist die Performance unter Last? Wie ist die Entwicklung des Speichers und der CPU seit dem letzten Release? Durch das Monitoringsystem möchten die Entwickler über technische Fehler informiert werden, um schnell reagieren zu können, am besten noch bevor es zum Worst-Case-Szenario kommt. Weiterhin werden nicht funktionale Anforderungen wie die Performance der Anwendung beobachtet.

Für den Betrieb ist das Hauptziel, eine hohe Verfügbarkeit der Anwendung zu gewährleisten. Daher müssen die Betriebsmitarbeiter frühzeitig Bescheid wissen, falls ein Teil der Anwendung nicht funktioniert. Falls eine große Belastung der Anwendung zu langsamen Antwortzeiten führt, kann auch dies eine interessante Metrik für den Betrieb sein. Weiterhin beobachten die Betriebsmitarbeiter die gesamte Infrastruktur der Anwendung wie Hardware, Netzwerk oder Betriebssystem. Werden Probleme erkannt, handeln sie selbst oder sie informieren die Entwickler.

Der Fachbereich definiert in der Anforderungserhebung die nicht funktionalen Anforderungen. So erwartet er, dass die Antwortzeit unter einer gewissen Zeitspanne bleibt oder dass die Anwendung 24/7 verfügbar ist. Aus den nicht funktionalen Anforderungen ergeben sich die Schwellwerte für die Metriken, die von Betrieb und Entwicklern beobachtet werden müssen. Ansonsten ist der Fachbereich an keinen technischen Metriken interessiert. Ihn interessieren aber weiterhin fachliche Fragen, die aus der Anwendung generiert werden können, z. B.: „Wie viele Verkäufe wurden vom Produkt X im bestimmten Zeitraum gemacht?“.

Alle Daten werden aus der Anwendung und der Infrastruktur erzeugt. Nicht nur im Zeitalter von Big Data heißt es, so viele Daten wie möglich zu sammeln, auch für die Erhebung von Monitoringdaten gilt diese Prämisse. Da die Daten aber aus unterschiedlichen Quellen kommen und für unterschiedliche Zielgruppen interessant sind, braucht es hier einen standardisierten Prozess.

Wie ändert sich das Monitoring?

Aus Sicht von Entwicklung und Betrieb ist das Monitoring von monolithischen Anwendungen recht einfach. Es gibt nur ein System, das überwacht werden muss. Das macht die Fehlersuche für die Entwickler übersichtlich: Sie müssen nur an einer Stelle nachsehen. Auch der Betrieb muss die Hardware und die Infrastruktur von nur einer Anwendung überwachen. Manchmal gibt es aus Performancegründen ein Clustering mit mehreren Knoten. Aber auch dann ist das System noch überschaubar.

Bei Microservices hingegen ist die Fachlichkeit auf viele kleine Services aufgeteilt. Jeder Microservice hat seine eigene Mikroarchitektur und lebt in seiner eigenen Infrastruktur. Jeder Microservice erstellt eigene Logs und Metriken und muss zum einen eigenständig und zum anderen im Zusammenspiel mit anderen Microservices beobachtet werden. Dies macht auch die Fehleranalyse schwierig. Denn zunächst muss identifiziert werden, welcher der zahlreichen Microservices die Ursache eines Fehlers ist. Abbildung 1 zeigt vereinfacht das eigentliche Problem beim Monitoring und Logging von verteilten Systemen auf: Es existieren viele Protokolle mit Logs und Monitoringdaten physisch an unterschiedlichen Stellen. Dazu kommt, dass sich ein fachlicher Prozess über mehrere Services hinwegziehen kann. Dadurch werden Logs und Monitoringdaten zu diesem Prozess an unterschiedlichen Stellen generiert.

fichtner_microservices_1.tif_fmt1.jpgAbb. 1: Eine monolithische Anwendung lässt sich einfacher überwachen als eine Microservices-Architektur

Die Lösung ist einfach: Logs und Monitoringdaten müssen zentral abgelegt werden. Die Kommunikation zwischen den Microservices muss protokolliert und konsolidiert werden. All diese Informationen müssen dem Benutzer an einer Stelle zur Verfügung stehen.

Relevante Kennzahlen identifizieren

Bevor man mit der technischen Umsetzung beginnen kann, müssen zunächst die relevanten Kennzahlen ermittelt werden. Grundsätzlich hängen die Anforderungen an die Kennzahlen stark von der Anwendung ab und müssen von den jeweiligen Zielgruppen definiert werden. Tabelle 1 zeigt verschiedene Metriken, die ein Monitoringsystem bei Bedarf bereitstellen sollte. Die Metriken sind nach den Zielgruppen aufgeteilt. Busin...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang