Konzept Überwachung

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 IsyFact 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 Betriebshandbuch der Anwendungssysteme 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.

5.3. Availability

Availability (Verfügbarkeit) eines Systems oder einer individuellen Systemkomponente ist definiert als der Prozentsatz eines Zeitraums, in welcher es ordnungsgemäß nach gesetzten Performance-Kriterien läuft (vgl. Oracle: Definition von Availability).

Availability = \frac{Erfüllungszeitraum der Performance-Kriterien}{Definierter Zeitraum des System-/ Komponentenbetriebs}

Das grundlegende Performance-Kriterium einer Anwendung ist deren korrekter Zustand und deren Erreichbarkeit. Daher sind Health-Checks essenziell dafür die Availability zu berechnen.

Diskussion und Anmerkung:

"Definierter Zeitraum": Eine Messung über einen Zeitraum von einer Woche, einem Monat oder bis zu mehreren Jahren kann bestimmt werden. Dieser kann gegliedert in abgetrennte Zeiträume erfolgen, oder jeweils den letzten zurückliegenden Zeitraum betreffen. Dieser ist wie die Performanz-Kriterien anwendungsspezifisch festzulegen.
Availability in Spring Boot: In Spring Boot ist keine Definition von Availability gegeben. Liveness und Readiness wird stattdessen unter Availability zusammengefasst (vgl. Spring Boot AvailabilityState).
Bedeutung der Definition: Es werden nicht-funktionale Anforderungen als Kriterien für Availability gesetzt. Diese stellen Anforderungen an die Anwendung, bzw. das System, auf welches diese verwendet wird, dar. Die nicht-funktionalen Anforderungen, aus deren Erfüllung sich die Availability ableitet, können nicht von den Standards vorgegeben werden. Sie müssen von der jeweiligen Anwendung gegeben werden, da für diese unterschiedliche Bedürfnisse an die Verfügbarkeit der jeweiligen Anwendung bestehen. Sind die nicht-funktionalen Kriterien erfüllt, dann ist die Anwendung/das System available. Availability als Messung des available Zustands über die Zeit stellt entsprechend dar, in welchem zeitlichen Umfang die nicht-funktionalen Kriterien erfüllt sind.
Praktischer Nutzen der Messung: Availability wird zur quantitativen Messung der Resilienz eines Systems und der Feststellung des Erreichungsgrads eines angestrebten Resilienz-Ziels genutzt (vgl. aws: Berechnung von Availability).

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.