Das System läuft. Bis zu dem Moment, in dem es aufhört
Stell dir einen Onlineshop vor, in dem Kundinnen und Kunden Produkte ansehen, sie in den Warenkorb legen und zur Zahlung übergehen können. Der Server antwortet, die Seite lädt, und die grundlegenden Infrastrukturmetriken deuten auf kein ernstes Problem hin. Auf den ersten Blick funktioniert alles korrekt.
In der Zwischenzeit können einige Kundinnen und Kunden ihre Bestellung nicht abschließen. Bei manchen dauert die Zahlung mehrere Sekunden, bei anderen erscheint ein Fehler. Das Technikteam erhält Meldungen, weiß aber noch nicht, ob die Ursache das Zahlungsportal, die Datenbank, das letzte Anwendungsupdate oder vielleicht ein Kommunikationsproblem zwischen Diensten ist.
Das ist eine Situation, in der herkömmliches Monitoring unzureichend sein kann. Es kann anzeigen, dass die Fehlerzahl gestiegen ist oder die Antwortzeit länger wurde, liefert aber nicht immer die Informationen, die nötig sind, um die Ursache schnell zu finden.
Genau diese Lücke schließt Observability, also die Beobachtbarkeit des Systems. Ihr Ziel ist nicht nur festzustellen, dass die Anwendung nicht korrekt funktioniert. Es geht um die Möglichkeit, ihr Verhalten zu analysieren, den Ablauf der Ereignisse zu rekonstruieren und die Problemquelle zu finden – auch dann, wenn zuvor kein konkretes Ausfallszenario vorgesehen wurde.
Monitoring und Observability - ähnliche Ziele, unterschiedliche Möglichkeiten
Monitoring und Observability sind eng miteinander verbunden, bedeuten aber nicht dasselbe.
Monitoring besteht darin, Daten über den Zustand von Anwendung und Infrastruktur systematisch zu erfassen und zu analysieren. Es ermöglicht, bestimmte Parameter zu verfolgen, Abweichungen von festgelegten Normen zu erkennen und Alarme auszulösen, wenn eine Reaktion erforderlich ist.
Beispielhafte Fragen, die Monitoring beantwortet, sind:
- Ist der Server erreichbar?
- Wie hoch ist die durchschnittliche Antwortzeit der API?
- Überschreitet die Anzahl der HTTP-500-Fehler den festgelegten Schwellenwert?
- Wie hoch ist die Auslastung von Speicher und Prozessor?
- Wächst die Warteschlange schneller, als das System sie verarbeiten kann?
Observability geht weiter. Sie ermöglicht es, Daten aus verschiedenen Teilen des Systems zu analysieren und in einen Kontext zu setzen, der hilft zu verstehen, warum ein bestimmtes Verhalten auftrat.
Das lässt sich in drei Fragen zusammenfassen:
- Monitoring: Ist etwas nicht in Ordnung?
- Diagnostik: Wo ist das Problem aufgetreten?
- Observability: Was ist passiert, warum und welche Auswirkungen hatte es auf den Systembetrieb?
Beobachtbarkeit ersetzt Monitoring nicht. Es ist ein Ansatz, der Monitoring und entsprechend aufbereitete Telemetriedaten nutzt, um eine tiefere Analyse des Anwendungsverhaltens zu ermöglichen. OpenTelemetry beschreibt Observability als die Fähigkeit, dem System anhand von Signalen wie Logs, Metriken und verteilten Traces Fragen zu seinem Verhalten zu stellen. <Cite ref="turn154932search0"/>
Drei Säulen der Observability: Logs, Metriken und Tracing
Die Grundlage der Beobachtbarkeit bilden drei Arten von Telemetriedaten: Logs, Metriken und Traces. Jede von ihnen zeigt einen anderen Aspekt des Anwendungsverhaltens. Erst ihre Korrelation liefert ein umfassenderes Bild der Situation.
1. Logs - was ist in der Anwendung passiert?
Logs sind strukturierte Aufzeichnungen von Ereignissen, die von der Anwendung, dem Betriebssystem, Servern, Datenbanken und anderen Infrastrukturelementen erzeugt werden.
Sie können zum Beispiel Folgendes erfassen:
- Start und Ende eines Prozesses,
- den Login-Versuch eines Nutzers,
- das Senden einer Anfrage an eine externe API,
- einen Datenvalidierungsfehler,
- eine fehlgeschlagene Transaktion,
- eine von der Anwendung ausgelöste Ausnahme,
- eine Änderung des Bestellstatus.
Ein Log kann Zeitstempel, Wichtigkeitsstufe, Servicename, Meldung, Anforderungs-ID sowie zusätzliche Attribute enthalten, die das Ereignis beschreiben.
Es lohnt sich, Text-Logs von strukturierten Logs zu unterscheiden. Ein Texteintrag kann etwa so aussehen:Fehler bei der Verarbeitung der Bestellung
Eine solche Meldung weist auf ein Problem hin, sagt aber wenig über seinen Kontext aus. Ein strukturiertes Log kann dagegen separate Felder enthalten, etwa Bestell-ID, Name der Operation, Fehlercode, Ausführungszeit und Trace-ID. Dadurch lassen sich die Daten filtern, gruppieren und automatisch analysieren.
Gute Praxis: Logs sollten mit Blick auf eine spätere Analyse gestaltet werden, nicht nur zum Speichern von Meldungen. Es lohnt sich, einheitliche Benennungen, Wichtigkeitsstufen und Korrelations-IDs zu verwenden, die Ereignisse aus verschiedenen Komponenten miteinander verknüpfen.
Gleichzeitig erfordert Logging Augenmaß. Das vollständige Protokollieren jeder Operation kann enorme Datenmengen erzeugen, die Speicherkosten erhöhen und das Finden relevanter Informationen erschweren. Ebenso wichtig ist, dass Logs keine Passwörter, Zugriffstoken, Kartendaten oder andere vertrauliche Informationen preisgeben. Es sollten Maskierung, Zugriffskontrolle, geeignete Aufbewahrungsfristen und sichere Datenverarbeitungsregeln angewendet werden.
2. Metriken - wie verhält sich das System im Zeitverlauf?
Metriken sind aggregierte numerische Daten, die den Zustand, die Leistung und das Verhalten eines Systems über einen bestimmten Zeitraum beschreiben.
Beispielhafte Metriken umfassen:
- die Anzahl der pro Sekunde bearbeiteten Anfragen,
- den Anteil der Anfragen, die mit Fehlern endeten,
- die Antwortzeit der API,
- die Nutzung von CPU und Speicher,
- die Anzahl aktiver Sitzungen,
- die Länge der Warteschlange,
- die Anzahl abgeschlossener Transaktionen,
- die Wartezeit auf eine Verbindung zur Datenbank.
Ihr größter Vorteil ist die Möglichkeit, Trends zu beobachten. Ein einzelner Fehler kann ein Einzelfall sein, doch eine allmählich steigende Antwortzeit, eine zunehmende Zahl fehlgeschlagener Transaktionen oder eine wachsende Warteschlange können auf ein entstehendes Problem hinweisen.
In der Praxis helfen Metriken nicht nur die Frage zu beantworten, ob die Anwendung funktioniert, sondern auch, ob ihre Leistung den Erwartungen der Nutzer und den geschäftlichen Anforderungen entspricht.
Besonders nützlich sind Antwortzeit-Perzentile, zum Beispiel p95 und p99. Der Durchschnitt kann eine Situation verschleiern, in der die meisten Nutzer schnell eine Antwort erhalten, aber ein kleiner Teil sehr lange Verzögerungen erlebt. Perzentile zeigen, wie lange die Bearbeitung langsamer Anfragen dauert, und helfen, Probleme sichtbar zu machen, die in Durchschnittswerten verborgen bleiben.
Gute Praxis: Wähle Metriken, die für den Nutzer und den Geschäftsprozess relevant sind. Allein die Information über die CPU-Auslastung sagt nicht, ob der Kunde eine Bestellung aufgeben kann. Es lohnt sich daher auch, Kennzahlen zu überwachen, die mit Kernfunktionen verbunden sind, etwa die Erfolgsquote von Zahlungen, die Dauer der Bestellabwicklung oder die Verfügbarkeit der wichtigsten Operationen.
3. Tracing - welchen Weg nahm die Anfrage?
Tracing, insbesondere Distributed Tracing, also verteiltes Tracing, ermöglicht es, den Weg einer einzelnen Anfrage durch verschiedene Komponenten des Systems nachzuverfolgen.
In einer modernen Anwendung kann eine Benutzeraktion viele Schritte umfassen. Ein Klick auf die Schaltfläche „Bestellung aufgeben“ kann eine Anfrage im Browser auslösen, die an die API, dann an den Bestelldienst, die Datenbank, das Lagersystem und einen externen Zahlungsanbieter weitergeleitet wird.
Wenn sich der Prozess verzögert, reicht die bloße Information über die Antwortzeit der gesamten API möglicherweise nicht aus. Tracing macht es möglich, diese Zeit auf einzelne Vorgänge aufzuschlüsseln und zu sehen, welcher Schritt für die Verzögerung verantwortlich ist.
Das grundlegende Element eines Traces ist ein Span, also die Aufzeichnung eines einzelnen Vorgangs. Ein Span kann Start- und Endzeit, den Namen des Vorgangs, den Status sowie Metadaten enthalten. Zusammengehörige Spans bilden einen Trace, der den Ablauf der gesamten Anfrage zeigt.
Zum Beispiel:
- Die API erhält eine Anfrage und leitet sie weiter.
- Der Bestelldienst validiert die Daten.
- Die Datenbank speichert die Bestellung.
- Der Lagerdienst prüft die Produktverfügbarkeit.
- Das externe Zahlungsgateway verarbeitet die Transaktion.
- Die Anwendung gibt das Ergebnis an den Benutzer zurück.
Wenn der gesamte Prozess 8 Sekunden dauert, kann Tracing zeigen, dass 6,5 Sekunden auf die Antwort des externen Zahlungsgateways entfielen und die übrigen Vorgänge korrekt abliefen. Das Team erhält dann einen konkreten Ansatzpunkt für weitere Analysen, statt mit der Fehlersuche bei zufälligen Komponenten zu beginnen.
Tracing ist besonders nützlich in Mikroservice-Architekturen, verteilten Systemen, warteschlangenbasierten Anwendungen und Lösungen, die viele externe Dienste integrieren. <Cite ref="turn154932search0"/>
Alarme – die Information muss die richtige Person erreichen
Telemetriedaten sind nur dann nützlich, wenn auf ihrer Grundlage gehandelt werden kann. Deshalb ist ein Alarmsystem ein wichtiger Teil von Observability.
Ein Alarm ist eine Benachrichtigung über ein Ereignis oder einen Zustand, der Aufmerksamkeit erfordert. Er kann ausgelöst werden, wenn ein Metrikschwellwert überschritten wird, ein bestimmtes Fehlermuster erkannt wird oder festgestellt wird, dass eine zentrale Funktion der Anwendung nicht wie erwartet funktioniert.
Nicht jeder Anstieg der Last sollte jedoch einen Alarm auslösen. Wenn das System regelmäßig hohen Verkehr zu Stoßzeiten verarbeitet, erzeugt eine Benachrichtigung bei jedem Anstieg der Anfragen Informationsrauschen. Zu viele Alarme führen dazu, dass sie ignoriert werden, und folglich dazu, dass ein tatsächlich wichtiger Vorfall übersehen wird.
Daher sollte man festlegen:
- welche Ereignisse eine sofortige Reaktion erfordern,
- welche Probleme im normalen Arbeitsmodus analysiert werden können,
- wer für einen bestimmten Alarmtyp verantwortlich ist,
- welche Informationen eine Benachrichtigung enthalten sollte,
- welche Maßnahmen nach ihrem Eingang ergriffen werden müssen.
Ein guter Ausgangspunkt ist die Definition von Alarmen auf Basis der Auswirkungen auf den Benutzer und der Zuverlässigkeitsziele, nicht ausschließlich anhand von Infrastrukturparametern. Ein Alarm über einen steigenden Anteil fehlgeschlagener Zahlungen kann beispielsweise geschäftlich wichtiger sein als ein kurzfristiger Anstieg der CPU-Auslastung.
Ein Alarm sollte zu einer Handlung führen. Wenn nicht klar ist, wer ihn bearbeiten soll und was zu tun ist, ist er nur eine weitere Meldung im System.
Praxisbeispiel: Wie hilft Observability dabei, die Ursache eines Ausfalls zu finden?
Nehmen wir an, Benutzer einer B2B-Anwendung berichten, dass das Erstellen von Berichten deutlich länger dauert als gewöhnlich. Monitoring erkennt einen Anstieg der Antwortzeit und löst einen Alarm aus.
Das Team beginnt mit der Analyse:
- Metriken zeigen, dass das Problem hauptsächlich Berichte mit großen Datenbereichen betrifft. Die übrigen Funktionen arbeiten normal.
- Tracing zeigt, dass die größte Verzögerung bei der Ausführung einer Datenbankabfrage auftritt.
- Logs enthalten Details zur Abfrage, ihre Betriebsparameter und Informationen zu Fehlern, ohne sensible Daten offenzulegen.
- Datenkorrelation ermöglicht es, einen konkreten Trace mit den entsprechenden Logeinträgen und den in den Metrikdiagrammen sichtbaren Änderungen zu verknüpfen.
- Änderungsanalyse zeigt, dass das Problem nach dem Rollout einer neuen Berichtsversion auftrat, die begann, eine kostenintensive Abfrage auszuführen.
Dadurch muss das Team nicht blind die gesamte Infrastruktur prüfen. Es kann sich auf eine konkrete Operation konzentrieren, das Verhalten vor und nach dem Rollout vergleichen und anschließend die Abfrage optimieren oder die Änderung zurücknehmen.
Observability beseitigt keine Ausfälle und garantiert nicht, dass jede Ursache automatisch gefunden wird. Es hilft jedoch, den Suchbereich einzugrenzen, die Diagnosezeit zu verkürzen und Entscheidungen auf Daten statt auf Annahmen zu stützen.
Datenkorrelation – der größte Wert entsteht gemeinsam
Logs, Metriken und Tracing sind einzeln nützlich, aber ihr wahrer Wert zeigt sich, wenn sie miteinander verknüpft werden können.
Stellen wir uns vor, ein Dashboard zeigt einen plötzlichen Anstieg der Antwortzeit. Die Metrik zeigt, wann und in welchem Ausmaß das Problem aufgetreten ist. Der Trace zeigt, welche Operationen die langsame Anfrage ausmachten. Die Logs ermöglichen es zu prüfen, welche Ereignisse in einem konkreten Schritt auftraten.
Damit das möglich ist, sollte das System den Kontext einer Anfrage konsequent zwischen Diensten weitergeben. Trace- und Span-IDs können verwendet werden, um Logeinträge mit Traces zu verknüpfen. Es ist auch sinnvoll, konsistente Informationen über den Dienstnamen, die Umgebung, die Anwendungsversion und andere Attribute beizubehalten, die die Datenquelle beschreiben.
Ohne Korrelation kann das Team zwar Zugriff auf viele Dashboards, Dateien und Werkzeuge haben, verliert aber dennoch Zeit damit, manuell festzustellen, welche Ereignisse miteinander verbunden sind. OpenTelemetry nennt die Korrelation von Logs, Traces und Ressourcenkontext als wesentliches Element beim Aufbau nützlicher Telemetrie. <Cite ref="turn154932search1"/>
OpenTelemetry – ein gemeinsamer Standard für Telemetriedaten
Die Einführung von Observability muss nicht bedeuten, an einen einzelnen Toolanbieter gebunden zu sein. Eine der Lösungen, die Interoperabilität unterstützen, ist OpenTelemetry (OTel) – ein offenes Set aus Standards, APIs, Bibliotheken und Werkzeugen zur Instrumentierung, Erzeugung, Erfassung und zum Export von Telemetriedaten.
OpenTelemetry ermöglicht es einer Anwendung, Metriken, Logs und Traces in einem konsistenten Modell auszugeben. Die Daten können anschließend an ein gewähltes Observability-Backend weitergeleitet werden, das für Speicherung, Suche, Visualisierung und Analyse verantwortlich ist.
Ein wichtiger Bestandteil des Ökosystems ist der OpenTelemetry Collector. Er kann Daten aus verschiedenen Quellen empfangen, verarbeiten, mit zusätzlichem Kontext anreichern und an konfigurierte Systeme exportieren. Dadurch muss die Anwendung nicht direkt mit jedem für die Analyse genutzten Tool verbunden sein.
Dieser Ansatz ist besonders nützlich, wenn ein Unternehmen viele Technologien nutzt, die Systemarchitektur weiterentwickelt oder die Möglichkeit behalten möchte, den Toolanbieter zu wechseln. Der Standard allein gewährleistet jedoch keine vollständige Observability. Weiterhin erforderlich sind eine geeignete Instrumentierung, eine durchdachte Strategie zur Datenerfassung, passende Dashboards, Alarme und Reaktionsverfahren. <Cite ref="turn154932search3"/>
Wann lohnt es sich, Observability einzuführen?
Observability kann sowohl in großen verteilten Systemen als auch in kleineren Anwendungen nützlich sein, bei denen ein Ausfall oder ein schwer zu erkennender Fehler erhebliche geschäftliche Folgen hat.
Besonders sollte man diesen Ansatz in Betracht ziehen, wenn:
- die Anwendung besteht aus vielen Diensten oder Integrationen,
- Probleme treten unregelmäßig auf und lassen sich schwer reproduzieren,
- Nutzer melden Fehler, die in Standardtests nicht sichtbar sind,
- die Zeit zur Diagnose von Vorfällen ist zu lang,
- weitere Deployments führen zu schwer vorhersehbaren Auswirkungen,
- das Unternehmen entwickelt das System weiter und benötigt Daten zur Leistungsplanung,
- die Anwendung unterstützt zentrale Vertriebs-, Betriebs- oder Finanzprozesse,
- das Team muss besser verstehen, welchen Einfluss externe Dienste auf das Funktionieren der gesamten Lösung haben.
Das bedeutet jedoch nicht, dass jede Website eine umfangreiche Telemetrie-Umgebung benötigt. Bei einem kleinen, einfachen Service können grundlegende Logs, Verfügbarkeitsüberwachung und einige Schlüsselmetriken ausreichen. Der Umfang der Lösung sollte der Komplexität der Anwendung, dem Verkehrsaufkommen, den Zuverlässigkeitsanforderungen und den Kosten möglicher Ausfallzeiten entsprechen.
Wann kann Observability zu viel des Guten sein?
Die Einführung umfangreicher Werkzeuge ohne klar definiertes Ziel kann mehr Kosten als Nutzen bringen.
Zu den häufigsten Fehlern gehören:
- Alles ohne Plan erfassen. Zu viele Daten erhöhen die Kosten und erschweren das Auffinden diagnostisch relevanter Informationen.
- Keine Fragen, auf die das System antworten soll. Dashboards können beeindruckend aussehen, aber nicht bei der Lösung realer Probleme helfen.
- Bei jeder Abweichung alarmieren. Zu viele Benachrichtigungen führen zu Alarmmüdigkeit und erhöhen das Risiko, einen Vorfall zu übersehen.
- Keine Zuständigkeit für die Reaktion. Selbst ein gut erkannter Fehler kann lange bestehen bleiben, wenn niemand weiß, wer sich darum kümmern soll.
- Fehlender Datenschutz. Telemetrie kann sensible Informationen, Nutzerkennungen oder Betriebsdaten enthalten, die eingeschränkten Zugriff und eine passende Aufbewahrung erfordern.
- Die Kosten der Instrumentierung ignorieren. Das Erfassen detaillierter Traces und Logs in großem Maßstab kann die Anwendungsleistung beeinträchtigen und erhebliche Kosten für Speicherung und Verarbeitung verursachen.
- Das Werkzeug als Komplettlösung betrachten. Die bloße Installation einer Plattform garantiert weder eine korrekte Instrumentierung noch einen effizienten Diagnoseprozess.
Observability erfordert daher nicht nur Technologie, sondern auch organisatorische Entscheidungen: welche Daten benötigt werden, wer sie analysiert, wie das Team reagiert und auf welche Weise Erkenntnisse aus Vorfällen in Änderungen am System umgesetzt werden.
Wie plant man die Einführung von Observability?
Am sichersten ist es, Observability schrittweise aufzubauen, beginnend mit den Prozessen und Funktionen, deren Ausfall die größte Auswirkung auf Nutzer und Unternehmen hat.
1. Die wichtigsten Geschäftsprozesse bestimmen
Identifiziere die wichtigsten Abläufe, etwa Anmeldung, Bestellaufgabe, Zahlungen, Dokumentenerstellung oder Datensynchronisation. Sie sollten der Ausgangspunkt dafür sein, zu definieren, was das ordnungsgemäße Funktionieren der Anwendung bedeutet.
2. Zuverlässigkeitskennzahlen festlegen
Wähle Metriken, die die Nutzererfahrung widerspiegeln, zum Beispiel die Verfügbarkeit zentraler Funktionen, die Antwortzeit oder den Anteil erfolgreich abgeschlossener Vorgänge. Für wichtige Dienste kann man SLI (Service Level Indicator), also einen Service-Level-Indikator, sowie SLO (Service Level Objective), also das Ziel für diesen Indikator, definieren.
3. Für strukturierte Logs sorgen
Vereinheitliche das Logformat, die Wichtigkeitsstufen und die grundlegenden Attribute. Achte auf Korrelations-IDs und auf eine Richtlinie zum Löschen oder Maskieren sensibler Daten. Logs sollten für das Team lesbar und durch Werkzeuge verarbeitbar sein.
4. Tracing auf kritischen Pfaden hinzufügen
Beginne mit Prozessen, die viele Dienste, Datenbanken oder externe Integrationen umfassen. Verfolge den Verlauf der Anfrage durch das System und achte auf die Weitergabe des Kontexts zwischen den Komponenten.
5. Dashboards um konkrete Fragen herum aufbauen
Statt ein einziges riesiges Panel zu erstellen, bereite Ansichten vor, die die Bedürfnisse verschiedener Rollen erfüllen. Das technische Team benötigt möglicherweise Informationen über Fehler und Verzögerungen, während der Produktverantwortliche Daten über die Wirksamkeit zentraler Prozesse und die Auswirkungen von Ausfällen auf Nutzer braucht.
6. Alerts und Reaktionsabläufe gestalten
Lege Schwellenwerte, Prioritäten, verantwortliche Personen und Vorgehensanweisungen fest. Ein Alert sollte den Kontext enthalten, der hilft, die Diagnose schnell zu beginnen, und nicht nur über das Überschreiten eines Werts informieren.
7. Observability testen
Prüfe, ob das Team anhand der verfügbaren Daten die Ursache eines Beispielfehlers finden kann. Man kann kontrollierte Ausfalltests in einer Testumgebung oder Übungen zur Vorfallreaktion durchführen. Es lohnt sich auch zu überprüfen, ob die Alerts genau dann ausgelöst werden, wenn sie es sollen.
8. Die Lösung auf Basis von Vorfällen weiterentwickeln
Nach jedem wesentlichen Problem sollte man prüfen, welche Informationen verfügbar waren, was gefehlt hat und wie Instrumentierung, Alerting oder Prozesse verbessert werden können. Observability ist kein einmaliges Projekt, sondern ein Prozess der fortlaufenden Verbesserung des Wissens über das Systemverhalten.
Kosten und Sicherheit - zwei Aspekte, die man nicht übersehen darf
Telemetriedaten haben ihren Preis. Kosten können durch Instrumentierung, Übertragung, Indizierung, Speicherung, Aufbewahrung und Datenanalyse entstehen. In Systemen mit hohem Traffic kann besonders das Sammeln aller Traces oder sehr detaillierter Logs teuer sein.
Deshalb lohnt es sich, eine an die Bedürfnisse angepasste Aufbewahrung, Datenfilterung, Sampling von Traces und unterschiedliche Detailstufen je nach Umgebung zu verwenden. Ein Produktionssystem kann zum Beispiel vollständige Daten für Fehler und ausgewählte kritische Vorgänge erfassen, während ein Teil der erfolgreichen Anfragen gesampelt wird, um das Datenvolumen zu begrenzen.
Ebenso wichtig ist der Datenschutz. Logs und Traces können unbeabsichtigt personenbezogene Daten, Sitzungskennungen, Teile von Abfragen oder Informationen über die Infrastrukturstruktur enthalten. Der Zugriff auf Telemetrie sollte eingeschränkt, unnötige Daten entfernt, sensible Informationen maskiert und Aufbewahrungsfristen kontrolliert werden. Es lohnt sich außerdem, Observability-Systeme als Teil der Produktionsumgebung zu betrachten, der selbst Absicherung, Backups und Berechtigungskontrolle benötigt.
Observability als Managementwerkzeug, nicht nur als Diagnoseinstrument
Obwohl Observability meist mit der Arbeit von Entwicklern, DevOps und Administratoren verbunden wird, reicht ihr Nutzen über den IT-Bereich hinaus.
Daten über Antwortzeiten, Fehler, Verfügbarkeit und die Wirksamkeit von Prozessen können einem Unternehmen helfen zu verstehen, welche Elemente der Technologie das Geschäft unterstützen und welche es einschränken. Sie ermöglichen es, wiederkehrende Probleme zu identifizieren, die Auswirkungen von Änderungen zu bewerten und die Weiterentwicklung auf Basis des tatsächlichen Systemverhaltens zu planen.
Wenn zum Beispiel das Bestellsystem zu bestimmten Tageszeiten regelmäßig langsamer wird, können Telemetriedaten helfen festzustellen, ob eine Abfrageoptimierung, eine Änderung der Aufgabenverarbeitung oder ein Ausbau der Infrastruktur erforderlich ist. Statt auf Grundlage von Intuition in zusätzliche Ressourcen zu investieren, kann das Unternehmen zunächst den tatsächlichen Engpass identifizieren.
Observability unterstützt auch die Analyse der Auswirkungen von Deployments. Der Vergleich von Metriken, Traces und Logs vor und nach einer Änderung ermöglicht es, Regressionen schneller zu erkennen und zu bewerten, ob das Update den erwarteten Effekt gebracht hat.
Man sollte Observability jedoch nicht mit automatischer Entscheidungsfindung gleichsetzen. Die Daten zeigen das Verhalten des Systems, aber ihre Interpretation erfordert Kenntnisse der Architektur, der Geschäftsprozesse und des Kontexts des jeweiligen Vorfalls.
Begriffslexikon
- Observability (Beobachtbarkeit) - die Fähigkeit, das innere Verhalten eines Systems auf Grundlage der von ihm ausgegebenen Daten zu verstehen.
- Monitoring - die kontinuierliche Überwachung ausgewählter Parameter und die Erkennung bestimmter, beachtungsbedürftiger Zustände.
- Telemetry (Telemetrie) - Daten, die aus Anwendungen und Infrastruktur gesammelt und zur Analyse ihres Verhaltens übertragen werden.
- Logs (Logs) - Aufzeichnungen von Ereignissen, die in einer Anwendung oder Infrastruktur auftreten.
- Metrics (Metriken) - numerische Messungen des Zustands, der Leistung oder des Verhaltens eines Systems über die Zeit.
- Tracing - das Verfolgen des Ablaufs von Operationen über die Komponenten einer Anwendung hinweg.
- Distributed tracing - das Verfolgen einer einzelnen Anfrage in einem System, das aus vielen Diensten oder Prozessen besteht.
- Span - die Aufzeichnung einer einzelnen Operation, die Teil eines Traces ist.
- Trace - eine Menge zusammenhängender Spans, die den Ablauf einer Operation darstellen.
- Alert - eine Benachrichtigung über einen erkannten Zustand oder ein Ereignis, das eine Reaktion erfordert.
- SLI - ein Indikator, der einen konkreten Aspekt des Betriebs eines Dienstes misst.
- SLO - ein festgelegtes Ziel für einen ausgewählten Zuverlässigkeitsindikator.
- Sampling - eine Technik zur Begrenzung der Menge gesammelter Telemetriedaten durch die Auswahl eines repräsentativen Teils der Ereignisse.
- OpenTelemetry - ein offener Satz von Standards und Tools zur Unterstützung von Instrumentierung und Export von Telemetriedaten.
Zusammenfassung
Ein Anwendungsfehler beginnt nicht immer mit einem nicht erreichbaren Server oder einer Fehlermeldung. Manchmal läuft das System formal, aber eine Schlüsselfunktion wird zu langsam, ein Teil der Transaktionen wird nicht erfolgreich abgeschlossen oder eine Integration schlägt nur unter bestimmten Bedingungen fehl.
Monitoring hilft, Unregelmäßigkeiten zu erkennen. Observability ermöglicht zu verstehen, was zu ihrem Auftreten geführt hat und welche Auswirkungen sie auf den Betrieb der Anwendung hatten. Logs, Metriken, Tracing und gut gestaltete Alerts bilden zusammen die Grundlage für eine effizientere Diagnose, bewusste Weiterentwicklung und die Reduzierung operativer Risiken.
Es geht nicht darum, so viele Daten wie möglich zu sammeln oder die umfangreichsten Dashboards zu erstellen. Es geht darum, im Moment eines Problems nicht nur zu fragen: „Funktioniert das System?“, sondern feststellen zu können: „Was genau ist im System passiert, warum und was sollten wir als Nächstes tun?”
Eine ausgereifte Anwendung ist nicht nur eine, die funktioniert. Sie ist auch eine, deren Verhalten man verstehen, diagnostizieren und verbessern kann.
