Was ist Observability?
Observability versteht sich als proaktive Erfassung, Visualisierung und kontextgenaue Auswertung aller Metrics, Events, Logs und Traces. Das Ziel dabei ist ein Punkt, an dem holistische Transparenz für das gesamte implementierte Software-System vorliegt.
Vereinfacht findet Observability darin Ausdruck, wie gut sich ein System anhand seiner Funktion im Live-Kontext auswerten lässt. In der Kontrolltheorie wird Observability als Bestimmungswert dafür definiert, wie präzise der externe Output eines Systems Rückschlüsse auf seinen internen Zustand liefert. Auf IT, Software und Cloud Computing angewendet und erweitert beschreibt Observability, wie akkurat Engineering-Teams den Status quo eines Systems mittels der von ihm generierten Daten erfassen können. Um dies in vollem Umfang zu gestalten, ist eine proaktive Erfassung der richtigen Daten vonnöten, dann ihre Visualisierung und abschließend die Korrelation mit Kontext.
Stellenweise wird Observability auch mit „o11y“ abgekürzt – die Zahl „11“ ersetzt dabei passenderweise die 11 Buchstaben zwischen „o“ und „y“. (Analog etwa auch zu „k8s“ für Kubernetes.)
Observability vermittelt Entwickler:innen einen proaktiven Ansatz zur Optimierung ihrer Systeme. Sie erhalten dabei einen mit Kontext angereicherten Echtzeit-Überblick aller operativ relevanten Daten in ihrem System. Und zudem die Möglichkeit, Fragen rund um Anwendungen und Infrastruktur im Detail auszuloten.
In welchem Kontext ist Observability relevant?
Im Zeichen von Kubernetes wandeln sich Software-Systeme hin zu komplexen cloudnativen, open-source- und microservice-basierten Strukturen. Ihre Entwicklung und ihre Deployments gehen mit immer höheren Cycle-Frequenzen einher, die von zunehmend verteilten Teams umgesetzt werden. DevOps, Continuous Delivery und agile Entwicklung haben dem gesamten Prozess der Software-Auslieferung ein noch nie gesehenes Tempo verliehen – das aber gleichzeitig teils in der Entstehung befindliche Probleme kaschiert.
So war die Identifikation von Ursachen in Zeiten von Mainframes und statischem Betrieb noch eine weitaus weniger anspruchsvolle Angelegenheit. Einleitbar war sie ganz einfach über vorkonfigurierte statische Dashboards. Traten Fehler auf, dann zumeist in einer bereits bekannten Systematik.
Im Zuge komplexer werdender Systeme sollten Monitoring-Tools dann neue Klarheit in die Performance von Software bringen, etwa mit Tracing-Möglichkeiten und Zeitreihenanalysen. Ein durchaus skalierbarer Prozess.
In der Gegenwart angelangt, hat sich die Gemengelage aber weiter gewandelt: Fehlern können eine immense Bandbreite an Ursachen zugrunde liegen, die sich für die Betrachter geradezu in die Unendlichkeit erstrecken: Liegt es an einem Server, der ausgefallen ist? An einem Cloud-Provider? Oder ist gerade neuer Code live geschaltet worden, der sich negativ auf die Endbenutzer-UX auswirkt?
Bei der Arbeit mit diesen komplexen verteilten Systemen ist die Identifikation der problematischen, ursächlichen Lücke in der gesamten Technologiekette ohne Observability nahezu unmöglich. Microservice-Architekturen haben die Zuständigkeiten teamübergreifend neu verteilt. So ist die Rolle eines klar definierten Anwendungs-Owners entstanden, die Zahl der im Gesamtprozess involvierten Teams gestiegen. Dabei gilt es jetzt, Bereiche detailgenau zu verstehen und zu analysieren und zudem Fehler in ihnen zu beheben, ohne notwendigerweise selbst diese erwähnte Ownership auszuüben. Hierfür notwendig ist zudem Distributed Tracing, mithilfe dessen der Pfad einer Abfrage – und ebenso auch von Bottlenecks – auf allen Ebenen eines verteilten Systems nachvollziehbar wird.
Observability und Monitoring: Der Vergleich
Konventionelles Monitoring stößt in der Welt der Microservices und verteilten Systeme an einem gewissen Punkt an seine Grenzen. Denn in seinem Wirkungskreis erscheinen können tatsächlich nur bekannte Unbekannte: Planbar erfassbare Konstellationen, Fragen und Anforderungen. Beispielsweise „Welchen Throughput hat meine Anwendung?“, „Welche Computing-Ressourcen stehen zur Verfügung?“ oder „Bei Überschreiten eines bestimmtem Fehlerbudgets Alert ausgeben“. Observability hingegen vermittelt nicht nur das Wissen dahingehend, dass etwas falsch läuft, sondern vor allem eben auch, warum dies so ist. Sie macht es möglich, auch Muster analysierbar zu machen, an die zuvor noch niemand auf dem Schirm hatte – die sogenannten unbekannten Unbekannten.
Eine nicht allzu geringe Vergleichbarkeit besteht mit Wortarten: Observability – ein Substantiv – bildet den Ansatz, um ein komplexes System zu verstehen. Monitoring – ein Verb – ist eine Aktion, die bei diesem Ansatz unterstützt. Observability ersetzt Monitoring nicht einfach. Vielmehr wird Monitoring zu einer der Techniken, die für das Enablement der höher geschalteten Observability grundlegend sind.
In Was ist APM? lesen Sie weitere Details zu Application Performance Monitoring.
Aus welchen Elementen setzt sich Observability zusammen?
Observability im Kontext digitaler Systeme setzt auf vier Tragsäulen auf:
- Offene Instrumentierung. Unter Instrumentierung verstehen wir die Erfassung und Messung von Daten, die Ihre Anwendung durchlaufen, dies mittels Code in Form von Agents. „Offene Instrumentierung“ beschreibt die Zusammenführung von Telemetriedaten aus Open-Source-Quellen und anbieterspezifischen Entitäten. Telemetriedaten sind etwa Metrics, Events, Logs und Traces, oft zusammenfasst als MELT. Beispiele für Entitäten sind Services, Hosts, Anwendungen und Container.
- Korrelation und Kontext. Ohne Gesamtbild keine Gesamtklarheit, die im Zusammenhang mit großen Enterprise-Anwendungen und ihren enormen Mengen an Telemetrie-Rohdaten natürlich umso wichtiger ist. Die Telemetriedaten selbst müssen auf Korrelation und Kontext analysiert werden, damit Engineering-Teams letztlich Muster und Anomalien klar ablesen können.
- Programmierbarkeit. Unternehmen müssen in der Lage sein, Custom-Anwendungen mit Ausrichtung auf ihre spezifischen Geschäftszielen zu entwickeln.
- AIOps-Tools. Damit moderne Infrastruktur auch mit Verfügbarkeit glänzt, ist eine beschleunigte Incident Response von tragender Bedeutung. Mit AIOps-Lösungen kommen dabei auf maschinellem Lernen basierende Technologien zum Einsatz, die Abläufe wie Korrelation, Aggregation und Priorisierung für Incident-Daten automatisieren. Unnötige Alerts werden so minimiert, Probleme proaktiv erfasst und im Ergebnis die Fehlerbehebung allgemein beschleunigt.
Welche Vorteile bietet Observability?
Observability-Tools unterstützen Engineering- und Developer-Teams dabei, CX-Erlebnisse zu gestalten, die auf ganzer Linie überzeugen, sowie bei der Navigation der zunehmenden Komplexität digitaler Umgebungen. Ferner machen sie es möglich, alle Telemetrie-Datentypen zu erfassen, zu analysieren, zu korrelieren und Alerts für sie zu definieren und auszugeben.
Optimierungen im operativen Kontext lassen sich leichter erarbeiten und umsetzen, Innovation und Wachstum greifbarer steuern. So ist es etwa möglich, über eine Observability-Plattform Incidents von kritischer Relevanz zu prüfen und sie für die Zukunft präventiv zu adressieren. Das Ergebnis: weniger Downtime, raschere Problembehebung.
Wird ein neuer Build live geschaltet, ist die Anwendungs-Performance direkt einsehbar. Ebenso werden nun auch Fehlerspitzen und abrupt hochschnellende Latenzzahlen genau nachvollziehbar. Liegt ein Node-Problem vor? Mit Observability ist feststellbar, an welchem genau. Weitere Beispiele finden Sie in den 10 Prinzipien der Observability, die Sie in unserem E-Book Observability 2021: Das Manifest im Detail nachlesen können.
Weitere Vorteile von Observability:
- De-facto-Informationsquelle für alle operativen Datenpunkte
- Verifizierbare Uptime und Performance
- Klarheit zu digitalen Performance- und Business-Fluktuationen
- Bessere teamübergreifende Zusammenarbeit bei der Fehlerbehebung
- Förderung einer Innovationskultur
- Skalierbare operative Effizienz zur Gestaltung hochwertiger Software-Erlebnisse und kürzere Release Cycles
- Details zur Entscheidungsfindung und Optimierung von Investitionen
Unsere Umfrage im Rahmen des Observability Forecast 2021 zeigt: Bei 90 % aller Befragten nimmt Observability eine strategisch wichtige Rolle für ihr Unternehmen ein, doch nur 26 % attestieren ihrem Framework einen hohen Reifegrad. Lediglich die Hälfte der nahezu 1.300 Befragten aus diversen Engineering- und Dev-Bereichen unterschiedlicher Hierarchiestufen berichteten von einer aktuell stattfindenden Observability-Implementierungsphase in ihrem Unternehmen.
Observability bieten Unternehmen unterschiedlichster Couleur herausragende Vorteile, doch nach wie vor bleiben signifikante Chancen ungenutzt.
Wer nutzt Observability?
SRE- und IT-Ops-Teams verantworten komplexe Systeme und mit ihnen ein ungemein breites Feld verschiedenster Anwendungen, auf deren Verfügbarkeit sich Benutzer:innen weltweit tagtäglich verlassen. Als Teil des Dev-Lifecycle ist Observability dabei aber für alle Beteiligten wichtiges Thema.
Denn mit ihr lassen sich Health-Status und allgemeine Performance in ihrer Gänze nachvollziehen – vom Wann bis hin zum Warum für Fehler aller Art. Durch Analyse von System-Output wie Events, Metrics, Logs und Traces können Entwickler:innen erfassen, wie es um die Performance eines Systems bestellt ist.
Observability und DevOps
Mit dem Einsatz von mehr und mehr microservice-basierten Strukturen hat auch die Anzahl der Deployments stark zugenommen. Um in diesen Umgebungen noch jeden möglichen Fehlermodus vorhersagen zu können, ändert sich hier viel zu viel dynamisch. Dabei müssen nicht nur der Anwendungs-Code, sondern auch Infrastruktur, Verbraucherverhalten und -nachfrage als kausal berücksichtigt werden.
Observability gibt DevOps-Teams die Flexibilität, die sie zum Testing ihrer Systeme in der Produktion benötigen – und um Problemen nachzugehen, die sie zuvor nicht hätten voraussehen können.
So unterstützt Observability DevOps-Teams konkret:
- Definition klarer Service-Level-Ziele und Implementierung von Instrumentierung zur Vorbereitung
- Konzertiertere DevOps mit Team-Dashboards, gemeinsamer Incident Response und Messbarkeit für jede Code-Änderung
- Nahtloses Tracking, Analysen von Anwendungsabhängigkeiten und Infrastruktur-Ressourcen sowie kontinuierliche Optimierung der UX
Auf konkrete Best Practices für DevOps gehen wir in unserem E-Book DevOps – so geht es richtig ein.
Ihr Start mit Observability: Testen Sie New Relic One.
Moderne Observability gibt Entwickler:innen eine datengestützte Methodik für den gesamten Software-Lebenszyklus an die Hand, zentralisiert dabei alle Telemetriedaten von Metrics und Events über Logs bis hin zu Traces in einer zentralen Plattform. Diese Komplettansicht für alle Daten wird kombiniert mit Analyse-Tools für den gesamten Stack. Das Ergebnis: Software, die überzeugende digitale UX möglich macht, und somit auch Innovation sowie geschäftliches Wachstum.
Mehr als nur plastisch vorstellen lässt sich die Technologie durch direkte Nutzung einer modernen Observability-Lösung.
Die in diesem Blog geäußerten Ansichten sind die des Autors und spiegeln nicht unbedingt die Ansichten von New Relic wider. Alle vom Autor angebotenen Lösungen sind umgebungsspezifisch und nicht Teil der kommerziellen Lösungen oder des Supports von New Relic. Bitte besuchen Sie uns exklusiv im Explorers Hub (discuss.newrelic.com) für Fragen und Unterstützung zu diesem Blogbeitrag. Dieser Blog kann Links zu Inhalten auf Websites Dritter enthalten. Durch die Bereitstellung solcher Links übernimmt, garantiert, genehmigt oder billigt New Relic die auf diesen Websites verfügbaren Informationen, Ansichten oder Produkte nicht.
