Observability mit Actuator, Metriken und Logging

Observability mit Actuator, Metriken und Logging

0:00 Dies ist das kürzeste Modul des Seminars und zugleich das, dessen Inhalt Sie am ehesten nachts brauchen werden. Denn eine Anwendung zu schreiben ist das eine — zu wissen, was sie gerade tut, ist etwas ganz anderes. Spring Boot bringt dafür Actuator mit, eine Sammlung von Endpunkten, über die eine laufende Anwendung Auskunft über sich selbst gibt.

0:20 Das ist mächtiger, als die meisten vermuten, und genau deshalb gehört zu diesem Modul auch eine deutliche Warnung. Was Ihnen beim Suchen von Fehlern hilft, hilft auch jemandem, der Ihre Anwendung ausspähen möchte.

Observability mit Actuator, Metriken und Logging

0:32 Drei Kapitel. Zuerst die Übersicht: Was ist Actuator, welche Endpunkte gibt es, wofür taugen sie. Dann die Praxis — einschalten, freigeben, hineinschauen, und dabei die Sicherheitsfrage klären. Und zum Schluss der Unterschied zwischen dem Zustand von jetzt und dem Verlauf über die Zeit. Das ist der Sprung von der Frage, ob die Anwendung läuft, zu der Frage, wie gut sie läuft und ob sich das gerade verschlechtert.

Spring Boot Actuator kennenlernen

0:58 Die Referenzdokumentation nennt den Abschnitt dazu Production-ready Features, und dieser Name ist eine gute Beschreibung. Es geht nicht um Entwicklung, es geht um alles, was nach der Auslieferung kommt. Actuator ergänzt Ihre Anwendung um Endpunkte, über die sie Auskunft über sich selbst gibt: ob sie gesund läuft, wie sie konfiguriert ist, wie sie Ressourcen verbraucht.

1:19 Man kann sich das wie die Diagnoseschnittstelle im Auto vorstellen — sie beeinflusst die Fahrt nicht, aber sie erlaubt jemandem mit dem richtigen Gerät, den Zustand auszulesen. Und ähnlich wie dort gilt: Wer Zugriff auf diese Schnittstelle hat, erfährt sehr viel. Neben den mitgelieferten Endpunkten können Sie auch eigene ergänzen, die anwendungsspezifische Auskünfte geben.

1:41 Diese Liste zerfällt in zwei Gruppen, und die Trennung ist wichtig. Die ersten drei sind Betriebsendpunkte — sie beantworten Fragen zum Zustand und werden typischerweise von Überwachungswerkzeugen abgefragt. Die unteren vier sind etwas anderes: Sie legen das Innere der Anwendung offen. Welche Beans registriert sind, welche Konfigurationswerte gelten, wie die Autokonfiguration entschieden hat, welche Anfrage zu welcher Methode führt.

2:06 Für die Fehlersuche ist das Gold wert. Für einen Angreifer allerdings auch. Merken Sie sich diese Zweiteilung, wir kommen im nächsten Kapitel darauf zurück. Der zweite Punkt ist der, der in Cloud-Umgebungen zählt: Kubernetes prüft über solche Endpunkte, ob eine Instanz lebt und ob sie bereit ist, Anfragen entgegenzunehmen.

2:25 Das ist keine Kosmetik — davon hängt ab, ob Verkehr auf eine Instanz geleitet oder eine hängende Instanz neu gestartet wird. Der vierte Punkt betrifft die Protokollierung: Strukturierte Protokolle sind maschinenlesbar, was in einer Umgebung mit vielen Instanzen den Unterschied macht zwischen auswertbar und unbrauchbar. Wenn zwanzig Container gleichzeitig Text schreiben, hilft freie Prosa niemandem mehr.

2:49 Der erste Punkt ist eine Fehleinschätzung mit Folgen: Actuator als Entwicklungswerkzeug zu betrachten und im Betrieb wegzulassen. Genau dort brauchen Sie es. Der zweite ist eine Wissenslücke — die Endpunkte lassen sich auch über JMX ansprechen, was in manchen Umgebungen der bessere Weg ist, weil sie nicht über HTTP nach außen reichen.

3:08 Und der dritte ist der Protokollpunkt von eben: Freie Textausgaben sind bequem zu schreiben und in einer verteilten Umgebung praktisch nicht auszuwerten.

Überwachen mit Actuator

3:17 Jetzt schalten wir es ein. Das ist schnell erledigt — und danach kommt der Absatz dieses Moduls, der mir am wichtigsten ist. Der Ablauf ist unspektakulär: Abhängigkeit ergänzen, starten, den Sammelpfad abfragen und die Liste ansehen. Interessant ist erst die Fußzeile. Ohne weiteres Zutun ist nämlich nur ein einziger Endpunkt über HTTP erreichbar, nämlich der zum Gesundheitszustand. Alles andere muss ausdrücklich freigegeben werden.

3:43 Das ist eine bewusste Entscheidung der Spring-Boot-Entwickler, und es ist die richtige: Die sichere Einstellung ist die Voreinstellung. Wenn Sie mehr wollen, müssen Sie es sagen — und in dem Moment denken Sie hoffentlich darüber nach, was Sie da freigeben. Was Sie hier sehen, ist eine Freigabeliste, und ich habe sie bewusst nicht mit einem Sternchen geschrieben, obwohl das möglich wäre.

4:06 Alles freizugeben ist die bequeme Variante und in der Entwicklung verlockend. Aber jeder freigegebene Endpunkt ist eine zusätzliche Angriffsfläche, wie die Fußzeile sagt. Überlegen Sie bei jedem Eintrag, wer ihn braucht. Und noch etwas: Diese Zeile ist eine ganz gewöhnliche Konfigurationseigenschaft. Damit gilt für sie alles aus Modul zwei — Sie können in der Entwicklung großzügig sein und die Liste in der Produktionsumgebung über eine stärkere Quelle wieder einschränken.

4:34 Diese vier Punkte sind Antworten auf Fragen, die wir in diesem Seminar schon hatten. In Modul eins ging es darum, dass Komponenten nicht gefunden werden, wenn sie außerhalb des durchsuchten Paketbaums liegen — der Bean-Endpunkt zeigt Ihnen, was tatsächlich registriert wurde. In Modul zwei ging es um die Rangfolge der Konfigurationsquellen und die Frage, welcher Wert sich durchgesetzt hat — genau das beantwortet der Umgebungsendpunkt.

4:58 In Modul eins hieß es, Autokonfiguration sei nur undurchschaubar, solange man nicht hinschaut; der Bedingungsendpunkt zeigt die Entscheidungen. Diese Endpunkte ersetzen also eine Menge Raterei. Jetzt der Absatz, auf den es mir ankommt. Alle Endpunkte freizugeben, heißt Ihre Anwendung von innen auszuleuchten — wer den Umgebungsendpunkt erreicht, sieht Konfigurationswerte, und dort stehen im Zweifel Verbindungszeichenketten und mehr.

5:23 Ohne Zugriffsschutz ist das eine offene Tür. Sorgen Sie also dafür, dass nur ein authentifizierter Administrator an diese Endpunkte kommt. Und der dritte Punkt ist der, der im Alltag passiert: Man gibt in der Entwicklung großzügig frei, weil man etwas sucht, und die Liste wandert unverändert mit in die Auslieferung. Prüfen Sie das vor jedem Release.

Metriken erheben

5:43 Zum Abschluss der Sprung von der Momentaufnahme zum Verlauf. Der Gesundheitsendpunkt beantwortet, ob es jetzt läuft. Metriken beantworten, wie es sich entwickelt — und das ist die Frage, die man früher stellen möchte. Metriken sind Werte, die man über die Zeit verfolgt: Prozessor- und Speicherverbrauch, Anfragen je Sekunde, Bearbeitungsdauer, Fehlerantworten je Zeitraum.

6:06 Der entscheidende Unterschied zum Gesundheitszustand ist die Zeitachse. Ein einzelner Messwert sagt fast nichts — dass die Anwendung gerade vierzig Prozent Speicher belegt, ist erst dann eine Aussage, wenn Sie wissen, dass es gestern zwanzig waren. Deshalb wandern Metriken üblicherweise in eine Zeitreihendatenbank, und ein Werkzeug wie Grafana baut daraus eine Übersicht. Erst diese Kette macht aus Zahlen eine Erkenntnis.

6:31 Der erste Aufruf listet auf, welche Metriken überhaupt zur Verfügung stehen — und das sind erstaunlich viele, ohne dass Sie etwas dafür getan haben. Der zweite ist der interessante: Er holt eine bestimmte Metrik und filtert dabei nach einem Etikett. Die Metrik zu den Serveranfragen liefert Anzahl, Gesamtdauer und längste Dauer der bearbeiteten Anfragen. Das allein ist schon nützlich.

6:52 Richtig aussagekräftig wird es aber erst durch die Etiketten, mit denen sich dieselbe Metrik aufschlüsseln lässt — im Beispiel nach dem Statuscode. Der zweite Punkt ist der praktische Gewinn: Fehlerhäufungen werden sichtbar, bevor jemand sie meldet. Stellen Sie sich vor, ein Endpunkt liefert seit dem letzten Release in fünf Prozent der Fälle einen Fehler.

7:13 Kein Nutzer schreibt deswegen ein Ticket — die meisten probieren es einfach noch einmal. In der Metrik sehen Sie es sofort. Der vierte Punkt schließt den Kreis: Ein Überwachungswerkzeug kann darauf Schwellen setzen und melden, wenn die Fehlerquote steigt. Damit wird aus einer Zahl ein Alarm, und aus einem stillen Problem ein bekanntes.

7:33 Die Aufgabe ist bewusst einfach gehalten: Erzeugen Sie ein paar erfolgreiche und ein paar fehlschlagende Anfragen — den Fehlerfall kennen Sie aus Modul drei, fragen Sie einfach nach einem Termin, den es nicht gibt. Weisen Sie dann in der Metrik nach, dass sich beide unterscheiden lassen. Das ist der ganze Mechanismus in klein.

7:52 Der Zusatz ist ein Aha-Erlebnis wert: Ändern Sie über den Protokollierungsendpunkt die Protokollstufe im laufenden Betrieb. Ohne Neustart, ohne Auslieferung. Wer schon einmal für mehr Protokollausgabe eine Anwendung neu starten musste, weiß, was das wert ist. Der erste Punkt ist der häufigste: Metriken werden erhoben, aber nirgends ausgeleitet.

8:13 Dann existieren sie nur im Speicher der laufenden Instanz — und genau in dem Moment, in dem Sie sie brauchen, nämlich nach einem Absturz, sind sie weg. Der zweite ist der Begriffsfehler, um den sich dieses Kapitel dreht. Und der dritte ist ein Ratschlag aus der Praxis: Schwellenwerte zu setzen, bevor man den Normalbetrieb kennt, führt zu Alarmen, die niemand mehr ernst nimmt.

8:34 Messen Sie erst, entscheiden Sie dann.

Was Sie aus Modul 6 mitnehmen

8:37 Vier Sätze. Actuator gibt Auskunft über die laufende Anwendung, nicht über den Code — es ersetzt keinen Test, aber es beantwortet Fragen, die kein Test beantworten kann. Freigeschaltet wird bewusst und sparsam, mit Zugriffsschutz davor; das ist der ernsteste Punkt dieses Moduls. Bei der Fehlersuche sparen Ihnen die Endpunkte zu Umgebung, Bedingungen und Zuordnungen viel Raterei.

9:00 Und Metriken zeigen den Verlauf, wofür sie ein Ziel außerhalb der Anwendung brauchen. Im letzten Modul bringen wir Radwerk dorthin, wo das alles zählt: in einen Container.