Was ist Observability?
Observability ist eine Denkweise, die es euch ermöglicht, jede Frage über euer gesamtes Unternehmen durch das Sammeln und Analysieren von Daten zu beantworten. Wenn man nach der Bedeutung von Observability (die manchmal auch als „Beobachtbarkeit“ bezeichnet wird) fragt, bekommt man oftmals entweder die trockene Definition aus der Systemsteuerungstheorie zu hören, laut der Observability „die Überwachung des internen Zustands eines Systems anhand seines Outputs“ ist, oder die sehr technische Definition von „Metriken, Traces und Logs“. Das ist zwar alles durchaus richtig, doch ist Observability nicht einfach etwas, das man implementiert und dann stolz verkündet: „Dieses System verfügt jetzt über Observability™“. Wenn ihr euer Unternehmen auf Observability ausrichtet, lassen sich unzählige Fragen über euer Unternehmen beantworten.
Welche Art von Fragen?
Natürlich können grundlegende Fragen wie „Was ist in unserer App passiert, als die Fehlerzahl in die Höhe schoss?“ mit Observability-Tools beantwortet werden, aber das kratzt kaum an der Oberfläche des eigentlichen Potenzials von Observability. Mit einer auf Observability ausgerichteten Denkweise könnt ihr herausfinden, warum die Fehlerzahl in die Höhe ging. Wenn ihr eure App und all ihre Abhängigkeiten in- und auswendig kennt, könnt ihr diese Erkenntnis vielleicht aus einem Monitoring-System gewinnen. Die zunehmende Komplexität moderner Apps macht es aber immer schwieriger, den Zustand der Apps zu überblicken. Geschäftsanforderungen, Einführungen neuer Produktfunktionen, A/B-Tests, Refactoring in Microservices usw... – alle diese Dinge lassen den Informationsgehalt ständig ansteigen, sodass es mit jedem Tag schwieriger wird, ohne helfende Tools alles über ein System zu wissen.
Mit Observability könnt ihr auch fragen, wie (oder ob!) die Fehler die User Experience konkret beeinträchtigt haben. Ihr könnt euch RUM-Daten, Kaufvolumen, allgemeine Geschäftsmetriken, Marketingkampagnen, Kundensupport-Tickets, die Stimmung in den sozialen Medien und noch vieles mehr ansehen. Durch diese Daten wird ein Observability-System von einem Spezial-Tool für wenige Nutzer zu einem Tool, das dem gesamten Unternehmen Einblicke ermöglicht. Mit diesen Daten könnt ihr nicht nur Antworten zum „Was“, sondern auch zum „Warum“ und „Wie“ erhalten. Mit einer echten Observability-Suite könnt ihr alle nachfolgenden Fragen beantworten:
- „Wodurch kam es zu dieser Störung?“
- „Wie wirkungsvoll war diese Werbeanzeige?“
- „Brachte das neue Front-End-Design Umsatzsteigerungen?“
- „Hat dieser Serviceausfall unsere Benutzer verärgert?“
Warum sollte euch das überhaupt interessieren?
Wenn ihr diese Art von Daten in euer System integriert, bemerkt ihr es, wenn bei einer Marketingkampagne mit euren besten Kunden als Zielgruppe die Call-to-Action-URL einen Tippfehler enthielt, durch den die Kunden auf einer 404-Fehlerseite landen. Ohne die vollständige Integration der Daten in die Observability-Lösung könntet ihr sicherlich feststellen, dass die Zahl der 4xx-Fehler steigt. Ihr könntet aber nicht herausfinden, warum die 4xx-Fehlerrate steigt, sondern eben nur, dass dies der Fall ist. Stellt euch vor, wie viel schneller ihr ein Problem lösen könntet, wenn zusätzlich zu „fe-server 4xx above threshold“ auch ein Event angegeben würde, das zeigt, dass zur gleichen Zeit die Marketingkampagne gestartet wurde („marketing campaign whales-winback started“). Ihr wüsstet dann nicht nur, dass ein Problem vorliegt, sondern könntet auch ziemlich schnell auf die Fehlerursache schließen und hättet zudem einen guten Ausgangspunkt, um die Auswirkungen auf den Umsatz oder den Ruf des Unternehmens zu untersuchen.
Worin liegt der Unterschied zu Monitoring?
Wie schon gesagt: Monitoring zeigt ein Problem auf, klärt aber nicht seine Ursache. Durch Monitoring lassen sich außerdem nur Dinge überwachen, die ihr bereits im Vorfeld als problematisch eingestuft habt (eure „known knowns“ / „bekannten Bekannten“.) Wenn ihr die betreffende Komponente nicht schon vorher instrumentiert habt, könnt ihr sie auch nicht überwachen. Was noch schlimmer ist: Wenn dann bei einer Komponente ein Problem auftritt und ihr entsprechende Monitoringmaßnahmen hinzufügen wollt, dann fehlen euch noch immer die historischen Daten über ihre Performance. Darüber hinaus müsst ihr beim Monitoring schon Entscheidungen treffen, bevor ihr überhaupt wisst, was schief gehen könnte – ihr müsst bestimmte Dinge gezielt instrumentieren und spezielle Benachrichtigungen dazu einrichten. Das ist zeitaufwändig und birgt ein großes Fehlerrisiko.
Hinzu kommt, dass sich auch mit einer sehr gut instrumentierten Monitoring-Lösung das eigene Unternehmen nicht vollumfassend erkunden und ausleuchten lässt. Die Analyse „unbekannter Unbekannter“ (unknown unknowns) ist mit einem klassischen Monitoring-System nicht möglich, weil für eine solche Auswertung die Daten gar nicht vorhanden sind. Das Hinzufügen von Geschäftsmetriken wird beim traditionellen Monitoring in der Regel nicht oder nur unzureichend unterstützt. Echte Benutzerdaten werden fast nie in Monitoring-Systeme einbezogen. Das ist völlig absurd, denn Sinn und Zweck all unserer Aktivitäten in Webanwendungen ist es ja schließlich, die passende Benutzererfahrung bereitzustellen!
Wie arbeiten die „drei Säulen“ zusammen?
Metriken, Traces und Logs sind die „drei Säulen“ der Observability. Sie sind notwendig, aber nicht ausreichend, um wirklich zu verstehen, was Observability ist, und um Einblicke in eure Anwendungen und das Geschäft zu erhalten. Mit Metriken könnt ihr feststellen, was schief läuft. Traces informieren euch, wie es schief läuft, also beispielsweise welche speziellen Aufrufe nicht funktionieren. Logs zeigen, warum es schief läuft: Sie ermöglichen euch, bestimmte Metriken/Traces eingehender zu untersuchen, um die Ursachen des beobachteten Verhaltens festzustellen. Das Erfassen dieser Daten ist der Beginn einer auf Observability ausgerichteten Denkweise – mehr aber auch nicht.
Muss man wirklich alle Daten berücksichtigen?
Vereinfacht gesagt, liegt ein großes Problem bei Observability in der Tatsache, dass es einfach zu viele Daten gibt, um sie alle zu erfassen und aufzubewahren. Ich höre immer wieder, es sei völlig unrealistisch, die von einem modernen Service erzeugte Ausgabemenge an einem Ort speichern zu wollen. Die meisten Anbieter schlagen als Lösung hier das Sampling, also die Verwendung von Datenstichproben vor – was in meinen Augen aber nur darauf hinausläuft, dass man Daten wegwirft. Bei den Daten, die man hierbei nicht berücksichtigt, könnte es sich um die Transaktion eures wichtigsten Kunden handeln. Es könnte sich dabei um genau den einen Use Case handeln, der zu einem seltsamen Programmfehler führt und euren Datenbankserver abstürzen lässt. Noch schlimmer ist, dass viele Anbieter dies als Funktion anpreisen, mit der sich „Geld sparen“ lässt. In einem separaten Blog gehe ich ausführlicher auf die versteckten Kosten des Samplings ein.
Würdet ihr in einem Umfeld mit klassischer Systemsteuerungstheorie, in dem kritische Infrastrukturen mit einer Reihe von Messgeräten überwacht werden, 70 % der Messergebnisse wegwerfen, weil „30 % genügen sollten“? Das würdet ihr natürlich nicht tun! Und doch ist es genau das, was viele Anbieter im Hinblick auf Observability und die Flut der Daten vorschlagen. Doch das ist schlicht falsch. Ausgereifte Plattformen können sämtliche Daten aus einem Unternehmen verwerten, ohne sie zuvor zu dezimieren.
Observability ist kein Verfahren, sondern eine Denkweise
In diesem Artikel wurden zwar schon einige Implementierungsdetails von Observability behandelt, doch Observability lässt sich wirklich nicht auf das Erfassen und Speichern von Metriken, Traces und Logs reduzieren. Im Gegenteil, sie ist eine Denkweise, ein Mindset mit Fragestellungen wie „Welche Daten sollten wir erfassen, weil sie beim Beantworten von Fragen über unser Geschäft wichtig sein könnten?“. Bei Observability geht es nicht nur um Application Performance Monitoring oder Infrastruktur-Monitoring (obwohl diese durchaus dazugehören). Es geht darum, zu verstehen, wie wichtig es ist, alle Daten zu erfassen. Echte Kennzahlen aus der Benutzererfahrung. Marketingkampagnen. Saisonale Änderungen der Besucherzahlen. Krankheitstage der Lagermitarbeiter.
Observability ist eine Denkweise, die eine einzige Informationsquelle für Daten über euer Unternehmen und eure Anwendungen erfordert, die jeder (Entwickler, Ops, Produkt, die Führungsebene usw.) nutzt. Es gibt Millionen von Datenpunkten, die euer Unternehmen ausmachen, und bei Observability geht es darum, all diese Daten in einem System zu erfassen und dann zur Beantwortung von Fragen zu nutzen, die über die technischen Anwendungen eures Unternehmens hinausgehen.
Um Observability optimal zu nutzen, benötigt ihr eine spezifische Streaming-Architektur, die sich beliebig skalieren lässt und ständig Rückmeldung dazu gibt, wie sich eure Änderungen auf eure Benutzer und euer Unternehmen auswirken. Ihr braucht ein System, das viele Tools in einer einzigen Informationsquelle bündelt und damit Erkenntnisse liefert.
Überzeugt euch selbst mit einer kostenlosen Testversion von Splunk Observability Cloud und profitiert noch heute von den damit gewonnenen Erkenntnissen.
Wenn ihr noch nicht für einen Test bereit seid und lieber erst noch mehr über das Thema Observability erfahren möchtet, dann lest am besten unser kostenloses E-Book Observability: Ein Leitfaden für Einsteiger durch.
----------------------------------------------------
Thanks!
Splunk
