© Liashko/Shutterstock.com
Entwickler Magazin
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?

Vitali Fichtner


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...

Entwickler Magazin
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?

Vitali Fichtner


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...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang