Konzept Überwachung

IFS-Logo Diese Seite ist ein Teil der IsyFact-Standards. Alle Inhalte der Seite, insbesondere Texte und Grafiken, sind urheberrechtlich geschützt. Alle urheberrechtlichen Nutzungs- und Verwertungsrechte liegen beim Bundesverwaltungsamt.

Creative Commons Namensnennung Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.

1. Einleitung

In diesem Konzept werden die Designvorgaben für die Überwachung von Anwendungen gemäß der Referenzarchitektur vorgestellt.

Die Realisierung einer einheitlichen Überwachungsschnittstelle erlaubt dem Betrieb frühzeitig Probleme in der Anwendungslandschaft zu erkennen und darauf zu reagieren. Dadurch können Ausfallzeiten minimiert werden.

Der Fokus des Konzepts liegt auf der Schaffung von einheitlichen Administrationsschnittstellen, welche dem Betrieb eine einfache Überwachung der Anwendungen erlauben. In Systementwürfen können Verfeinerungen der hier getroffenen Vorgaben gemacht werden. Weiterhin können die hier gemachten Vorgaben als Basis für die Beschreibung der Überwachungsschnittstelle im Systemhandbuch verwendet werden.

2. Kurzeinführung in Spring Boot Actuator

Spring Boot bringt mit Actuator eine Reihe zusätzlicher Funktionen mit, die dabei helfen, Anwendungen zu überwachen und zu verwalten. Die Kommunikation mit der Anwendung erfolgt über sogenannte Endpoints. Diese können über HTTP oder JMX bereitgestellt werden. Actuator bringt eine Reihe von eingebauten Endpoints mit und bietet auch die Möglichkeit, eigene Endpoints hinzuzufügen. So wird für Informationen über den Systemzustand die Endpoints health, livenessProbe, ReadinessProbe angeboten und über den Endpoint metrics können Metriken gelesen werden.

Weitergehende Details zu den Actuator Endpoints können bei Spring Boot Actuator Endpoint nachgelesen werden.

3. Informationen über den Systemzustand

Zur Überwachung von Anwendungen unterscheiden wir zwischen zwei unterschiedlichen Konzepten, dem health-Endpoint sowie Liveness und Readiness einer Anwendung.

Der health-Endpoint ist der ursprüngliche Status, über den der Zustand und die Erreichbarkeit einer Anwendung geprüft werden kann.

Liveness und Readiness sind zusätzliche Überwachungsmöglichkeiten. Durch die Unterscheidung in dies zwei Zuständen kann im Gegensatz zu dem health-Endpoint ein feingranulares Monitoring ermöglicht werden.

In der IsyFact wird (Stand IsyFact 3.0) standardmäßig der health-Endpoint verwendet. Mit der IsyFact 3.0 werden Liveness und Readiness konzeptionell zur Verfügung gestellt. Diese Endpoints sind in den Bibliotheken nicht standardmäßig eingebaut und müssen individuell eingeschalten werden.

3.1. health-Endpoint

Über den health-Endpoint wird durch einen Health-Check der eigene Zustand sowie die Erreichbarkeit aller angebundener Nachbarsysteme dargestellt.

Anders als von Spring vorgesehen entkoppelt die IsyFact den Health-Check vom Aufruf des Endpoints health. Durch diese Entkopplung wird die Systemstabilität durch häufige Aufrufe des Endpoints nicht beeinflusst.

Der Status der health-Endpoints wird maßgeblich von Nachbarsystemchecks bestimmt. Einzelheiten finden sich dazu in Kapitel Nachbarsystemchecks über health-Endpoints.

Implementiert und konfiguriert wurde bzw. wird der Health-Check als Task.

3.2. Liveness und Readiness

In diesem Kapitel werden die Begriffe Liveness und Readiness definiert. Die Bedeutung von "live" und "ready" Zuständen von Anwendungen und Services wird beschrieben. Erläutert wird, wie diese mit der Hilfe von Liveness- und Readiness-Probes in Spring Boot überwacht werden können.

3.2.1. Liveness

Eine Anwendung wird als "live" (lebendig) angesehen, wenn diese in einem korrekten inneren Zustand ist. Ist eine Anwendung nicht "live", ist ihr innerer Zustand defekt und kann nicht wiederhergestellt werden. Die Anwendung muss daher auf jeden Fall neu gestartet werden (vgl. Spring Boot LivenessState, Kubernetes Liveness und Readiness Probes).

3.2.2. Readiness

Eine Anwendung wird als "ready" (bereit) angesehen, wenn sie live ist und bereit für Anfragen ist. Ist eine Anwendung nicht "ready", kann sie temporär keine Anfragen bearbeiten. Ist eine Anwendung nicht "ready", darf die Infrastruktur keine weiteren Anfragen an sie senden (vgl. Spring Boot ReadinessState, Kubernetes Liveness und Readiness Probes).

Ein Service (d.h. eine Bündelung von Instanzen/Anwendungen, die denselben Service anbieten) wird als "ready" angesehen, wenn mindestens eine Instanz "ready" ist. Prüfungen der Readiness von Services müssen über die Infrastruktur erfolgen.

3.2.3. Diskussion von Liveness & Readiness

Zur Verdeutlichung und Trennung der beiden Begriffe werden diese an dieser Stelle zusammen behandelt. Der Fall, dass eine Anwendung, die nicht "live", aber "ready" ist, ist rein akademisch. In dem Moment, in dem eine Anwendung nicht "live" ist, muss sie durch die Infrastruktur neu gestartet werden, da sie aufgrund des inkorrekten inneren Zustands keine Anfragen korrekt bearbeiten kann. Aus praktischer Sicht wird die Liveness-Abfrage zur Evaluierung, ob eine Anwendung neu zu starten ist, genutzt. Eine Anwendung, die "live", aber nicht "ready" ist, ist in einem korrekten Zustand, hat aber nicht alle notwendigen Abhängigkeiten oder Ressourcen zur Verfügung, um Anfragen anzunehmen. Aus praktischer Sicht ist diese nicht neu zu starten.

Ist für eine Anwendung die Abfrage beider Zustande vorgesehen, ergeben sich folgende Zustände:

Tabelle 1. Unterscheidung zwischen Liveness- und Readiness-Zustand
korrekter innerer Zustand & bereit für Anfragen korrekter innerer Zustand & nicht bereit für Anfragen inkorrekter innerer Zustand → nicht bereit für Anfragen

Liveness-Zustand

korrekt (up)

korrekt (up)

inkorrekt (down)

Readiness-Zustand

korrekt (up)

inkorrekt (down)

inkorrekt (down)

4. Bestimmung von Metriken (Micrometer)

Die im Endpoint metrics bereitgestellten Metriken werden von Micrometer erfasst. Micrometer bietet eine einfache anbieterneutrale Fassade für die gängigsten Überwachungssysteme und ermöglicht es, Metriken im Anwendungscode ohne Herstellerbindung zu implementieren. Seit Spring Boot 2.0 ist Micrometer die Standardbibliothek zur Bereitstellung von Anwendungsmetriken von Spring.

Für eine Liste der unterstützten Monitoring-Systeme siehe unterstützte Monitoring-Systeme

5. Fachliche Möglichkeiten im Zusammenhang mit Health-Checks

Die Überwachung von Systemzuständen wird durch verschiedene fachliche Möglichkeiten aufgegriffen. Auf die Verwendung dieser und die Bereitstellung der Health-Checks wird in diesem Kapitel eingegangen.

5.1. Nachbarsystemcheck

Im Rahmen der periodischen Health-Checks wird die Erreichbarkeit aller angebundenen Nachbarsysteme geprüft (Nachbarsystemcheck). Jede Anwendung führt periodisch einen Health-Check durch, um den eigenen Zustand und die Erreichbarkeit aller angebundenen Nachbarsysteme zu prüfen.

Bei der Prüfung von Nachbarsystemen muss unterschieden werden, ob ein Nachbarsystem essenziell, oder nicht-essenziell für die prüfende Anwendung ist. Ein Health-Check mit negativem Ergebnis eines essenziellen Nachbarsystems muss in der health der prüfenden Anwendung sichtbar sein.

Die Nachbarsystemchecks können individuell konfiguriert werden. So kann z. B. konfiguriert werden, ob ein Nachbarsystem essenziell ist oder nicht. Details hierzu finden sich in den Nutzungsvorgaben.

5.1.1. Nachbarsystemchecks über health-Endpoints

Die Nachbarsystemchecks werden über Health-Checks der Nachbarsysteme durchgeführt.

Schlägt ein Health-Check eines Nachbarsystems fehl, führt dies zu einem Eintrag im technischen Log. Bei einem nicht essenziellen Nachbarsystem wird darauf eine Warnung geloggt. Bei einem essenziellen Nachbarsystem wird ein Fehler geloggt und die health des prüfenden Systems muss ebenso einen Fehler aufweisen.

5.1.2. Nachbarsystemchecks über Liveness/Readiness Endpoints

Im Rahmen von Nachbarsystemchecks kann (alternativ zum health-Endpoint) die Liveness und Readiness überprüft werden. Auch hier kann unterschieden und geloggt werden, ob ein essenzielles Nachbarsystem ausgefallen ist - oder ein nicht essenzielles. Ist ein essenzielles Nachbarsystem ausgefallen, dann hat dies Auswirkungen auf die Readiness des Systems. Nachbarsystemchecks von essenziellen Systemen sind damit essenziell für die Readiness eines Systems.

5.2. Loadbalancer

Ein Loadbalancer ist ein Netzwerkgerät, mit dem eingehende Anfragen auf mehrere Server verteilt werden. Durch dieses Loadbalancing wird die Ressourcenauslastung, die Reaktionszeit und die Ausfallsicherheit optimiert. Für Anwendungen nach der IsyFact-Architektur sollen einzelne Knoten eines Anwendungsclusters aus dem Loadbalancing herausnehmbar sein. Dies ist für das Durchführen von Updates erforderlich. Aus diesem Grund wird als Teil jeder Webanwendung ein sog. Loadbalancer-Servlet ausgeliefert.

5.2.1. Beschreibung des Loadbalancer-Servlets

Das Loadbalancer-Servlet prüft beim Aufrufen seiner URL, ob eine IsAlive-Datei im Konfigurationsverzeichnis vorhanden ist. Ist eine solche Datei vorhanden, liefert das Servlet den HTTP-Statuscode HTTP OK (200) zurück. Falls keine IsAlive-Datei gefunden wird, liefert das Servlet den Code HTTP FORBIDDEN (403) zurück. Der Loadbalancer prüft in regelmäßigen Abständen die URL des Servlets und nimmt für die Anwendung den entsprechenden Server aus dem Loadbalancing heraus, falls kein HTTP OK gelesen wird. Zu beachten ist, dass auf einem Server prinzipiell mehrere verschiedene Anwendungen laufen können. Der Loadbalancer muss daher so konfiguriert werden, dass auf dem Server nur die betreffende Anwendung deaktiviert wird, zu der das Loadbalancer-Servlet gehört. Alle anderen Anwendungen auf dem entsprechenden Server müssen weiterhin bedient werden.

5.2.2. Loadbalancing mit Readiness-Metrik

Sind Liveness und Readiness definiert, soll der Loadbalancer die Readiness eines Knotens prüfen. Ist die Readiness nicht gegeben, ist der Knoten aus dem Loadbalancing heraus zu nehmen. Je nach betrieblichen Bedingungen und den technischen Möglichkeiten des eingesetzten Loadbalancers ist die Abfrage der Readiness über den Readiness Endpoint oder eine isAlive-Datei festzustellen. Die betrieblich begründete, temporäre Nichtverfügbarkeit einer Anwendung, kann über die Löschung einer isAlive-Datei gesteuert werden (vgl. Nutzungsvorgaben). Ist das Vorhandensein einer isAlive-Datei aus betrieblichen Anforderungen nicht notwendig ist die direkte Prüfung über den Readiness Endpoint vorzunehmen.

6. Festlegungen und Ausgrenzungen

Die Nutzungsvorgaben finden sich in den Nutzungsvorgaben Überwachung.

Das Konzept für die Prüfung der Verfügbarkeit ist:

  • Anwendungen nach IsyFact-Architektur sollen Mechanismen bereitstellen, die es erlauben, die Verfügbarkeit der Anwendung durch eine betriebliche Überwachung zu prüfen.

  • Grundlage dafür ist die Bereitstellung eines HealthIndicators und einer Ping-Methode durch die Anwendung.

Folgende Punkte sind bewusst nicht Teil dieses Konzeptes:

  • Micrometer unterstützt die Anbindung zahlreicher Monitoring-Systeme. Es werden keine Vorgaben zur Verwendung eines bestimmten Systems gemacht.