Observability - Eine gesamtheitliche Sicht

Observability

Nachdem sich die Welt noch nicht einig ist, wie sie “Observability” definieren soll, hier die Definition für dieses Dokument:

Definition: Observability ist ein Maß, wie gut man den inneren Zustand einer Applikation anhand seiner Ausgaben erkennen kann. 

Wir denken dabei an Sachen wie:

• Gibt es Fehler bei der Verarbeitung?
• Wie viel Speicher benötigt die Applikation?
• Wie lange dauern die Requests?
• Wie war der Programmverlauf dieser fehlerhaften Anfrage?

Um solche Fragen zu beantworten, hat der Betrieb eine Reihe von Werkzeugen bereitgestellt. Die reichen von zentralem Logging (z.B. ELK-Stack) über die Sammlung von Metriken (z.B. Prometheus) und Performance Monitoring (z.B. Dynatrace) bis zu Tracing Werkzeugen (z.B. Jaeger).

Shift Left

Observability ist also eine Angelegenheit des Betriebs. Oder nicht? Unter dem Schlagwort “Shift left observability” wurde in letzter Zeit ein Konzept beschrieben (z.B. hier), demgemäß Observability nicht nur eine Angelegenheit des Betriebs ist, sondern in den Kern des Entwicklungsprozesses eingebettet wird. Damit folgt Observability dem DevOps Trend, demgemäß Entwickler und Betriebsmitarbeiterinnen gemeinsam für Stabilität und Funktionalität der Applikationen verantwortlich sind. Observability Werkzeuge und deren Daten werden schon in der Entwicklung berücksichtigt. Die äußert sich z.B. darin, dass für Problemanalysen hilfreiche Metriken von der Entwicklung in den Code eingebaut werden.

And Up

Die Entwickler in das Observability Thema einzubeziehen halten wir für eine gute Idee, aber richtig *** wird es dann, wenn wir auch den Fachbereich mit einbeziehen. Für Entwickler ist es heutzutage extrem einfach (z.B. mit Microprofile Metrics) Metriken zu veröffentlichen und die Auswertungswerkzeuge (z.B Grafana) haben eine Qualität, mit der auch Nichttechniker gut zurechtkommen. Mit ein paar Codezeilen können wir daher dem Fachbereich einen aktuellen Einblick in ihre Anwendung geben, der früher nicht, nur mit viel Aufwand oder im Nachhinein mittels Datawarehouse Auswertungen gegeben werden konnte. Wo früher z.B. bei Batch-Programmen Reports geschrieben wurden, die irgendwo am Filesystem liegen geblieben sind, können wir heute mit ein paar Zeilen Code praktisch in Echtzeit (wenige Sekunden Verzögerung) den Fortschritt unseres Programms sehen oder auch wie es genutzt wird:

• Aktuelle Anzahl an Kunden im System
• Anzahl an Bestellungen
• Getätigter Umsatz

Der Fachbereich erhält damit ein Business Activity Monitoring Werkzeug.

 Und als zusätzliches Highlight können wir Alerts definieren, die uns benachrichtigen, wenn mal etwas nicht so läuft wie es soll. Z.B. wenn plötzlich viel zu wenige Bestellungen ins System kommen.

Openly Shift

Die ursprünglich für den technischen Betrieb von Applikationen entwickelten Werkzeuge eröffnen uns eine Vielzahl neuer Möglichkeiten, um auch den fachlichen Zustand unserer Anwendungen besser beobachten zu können. “Observability” sollten wir daher nicht nur technisch, sondern auch fachlich verstehen.

Und ja, das ganze läuft besonders gut auf OpenShift, muss aber nicht 🙂.