LuckyStep - stock.adobe.com
Die drei Säulen der Observability sind oft nicht genug
Häufig werden als Grundlage von Observability drei Säulen – oder Datenquellen genannt. Doch manchmal schränkt diese Herangehensweise den Blick eher ein als klassisches Monitoring.
Observability ist das neueste Buzzword, im IT-Monitoring-Bereich. Aber was bedeutet es? Und woher wissen Sie, wenn ein Anbieter Ihnen eben nur Buzzwords anstelle sinnvoller Funktionen verkauft?
In diesem Artikel erläutern wir, was Observability in der Praxis bedeutet und ob die oft beschworenen drei Säulen der Observability für Ihre Architektur wirklich der richtige Ansatz sind.
Was ist Observability?
In der IT-Branche beschreibt der Begriff Observability die Fähigkeit, anhand messbarer Daten nachzuvollziehen, was innerhalb eines Systems passiert. Sie verwenden also Informationen, die Sie von außen einsehen können, wie Protokolldateien und Metriken, um herauszufinden, was tief im Inneren eines Systems passiert.
Jenseits dieser Definition reicht der Begriff Observability jedoch Jahrzehnte zurück. In den letzten Jahren haben sich Anbieter für Tools zur Überwachung und Fehlerbehebung in Anwendungsumgebungen den Begriff angeeignet.
Observability versus Überwachung versus Visibility
Viele Anbieter von Überwachung (auch bekannt als Monitoring) sehen das Ausgeben von Warnungen als Hauptfunktion ihrer Tools, während Observability laufend Berichte darüber liefert, was im System passiert. Zudem geht es bei letzterer auch darum, Informationen aus verschiedenen Teilen der Infrastruktur in ihrem Kontext zueinander darzustellen. Somit bietet Observability einen tieferen Einblick als Überwachung.
Daneben gibt es auch noch Visibility (wörtlich: Sichtbarkeit), bei der es um das Auswerten jeweils einzelner Datenquellen geht, während Observability Daten aus verschiedenen Umgebungen korreliert, um auch die Beziehungen zwischen ihnen abzubilden.
Mit derart feinen Abgrenzungen, die naturgemäß verschwimmen, ist es fraglich, inwiefern sich Observability, Visibility und Monitoring tatsächlich unterscheiden. Obwohl sich Tools und Techniken in den letzten Jahren weiterentwickelt haben, um auch Cloud-nativen, auf Microservices basierenden Architekturen gerecht zu werden, unterscheidet sich die Observability in der Vorgehensweise nicht grundlegend von regulärer Überwachung. Sie ist nur ein bisschen raffinierter.
In der Praxis ist Überwachung viel mehr als die simple Idee, Sie nur zu warnen, wenn etwas nicht stimmt. Ihr Zweck ist es, die Ursache von Systemfehlern zu identifizieren und dann Lösungen bereitzustellen. Dazu gehört auch, diese Probleme vorherzusagen, damit Administratoren eingreifen können, bevor Fehler sich auf den Betrieb auswirken. Diese Praktiken verwenden IT-Teams schon länger, als es den Begriff Observability gibt.
Darüber hinaus sind die wichtigsten Datenquellen für die Observability – die drei unten aufgeführten Säulen der Observability – seit langem Teil von Überwachungsroutinen. Observability hat kein Monopol auf Logs, Metriken und Traces.
Bei der Debatte Observability versus Überwachung versus Visibility handelt es sich also weitgehend um Semantik und Marketing. Somit sollten Sie Observability am besten als eine weiterentwickelte Form der Überwachung betrachten und nicht als einen radikalen Umbruch. Die mit Monitoring und Observability verbundenen Tools, Prozesse und Datenquellen sind sich im Grunde sehr ähnlich.
Die drei Säulen der Observability
Observability-Software bezieht Informationen aus den drei Hauptsäulen oder Datenquellen, die Einblicke in Systeme bieten:
- Protokolle. Informationen zu Infrastruktur- und Anwendungsaktivitäten, die einen einzigen Zeitpunkt erfassen
- Metriken. Details zur Leistung von Anwendungen und Cloud-Diensten
- Traces. Anfragen innerhalb eines verteilten Systems
Diese Säulen sind in den meisten Architekturen die wichtigsten Datenquellen, auf die sich moderne Monitoring- oder Observability-Tools stützen. Es ist jedoch aus mehreren Gründen etwas engstirnig, sich allein auf diese drei Säulen zu versteifen: Nicht jedes System verfügt über Protokolle, Metriken und Traces
Einige Cloud-Dienste stellen beispielsweise nur Metriken und keine Protokolle bereit. Diese Systeme sind immer noch beobachtbar, aber ihre Observability beruht nicht auf jeder der drei Säulen.
Monolithische Anwendungen nicht vergessen
Verteiltes Tracing funktioniert nur für Microservices-Anwendungen, nicht für monolithische. Sofern Sie monolithische Anwendungen nicht von vornherein aus Ihrer Observability-Strategie ausschließen möchten, sind Traces somit keine unumgängliche Voraussetzung.
Synthetische Überwachung
Sogenannte synthetische Überwachungstechniken helfen dabei, die Systemleistung zu bewerten und vorherzusagen, bevor Software in die Produktion wechselt. Sie konzentrieren sich normalerweise auf das Sammeln von Daten aus Tests und nicht auf herkömmliche Protokolle, Metriken und Traces.
Observability ist selbstverständlich nicht dasselbe wie synthetische Überwachung und somit wäre die Überzeugung, Logs, Metriken und Traces seien die Datenquellen für Observability, nicht in Zweifel gezogen.
Man könnte jedoch argumentieren, dass synthetisches Monitoring eine Möglichkeit ist, Observability zu erreichen, bevor das System überhaupt in die Produktion geht und somit dennoch ein wichtiger Teil der Überwachungsstrategie insgesamt ist. In diesem Fall müsste man dann den drei Säulen der Observability noch die Tests hinzufügen.
Weitere Datenquellen
IT-Teams müssen manchmal Logs, Metriken und Traces mit Daten aus anderen Systemen wie Ticketing-Systemen oder CI/CD-Pipeline-Performance (Continuous Integration/Continuous Delivery) kontextualisieren, um ein umfassendes Bild des Gesamtzustands des Softwarebereitstellungsvorgangs zu erhalten. Wenn Sie sich allein auf die drei Säulen der Observability konzentrieren, riskieren Sie, andere wichtige Quellen für die Transparenz Ihrer Systeme zu übersehen.
Observability liegt im Auge des Betrachters
Verzetteln Sie sich nicht in semantischen Debatten darüber, was Observability ist und was nicht – oder ob Logs, Metriken und Traces allein die wesentlichen Säulen der Observability sind. Es ist sinnvoller, Observability mit den gleichen Zielen und der gleichen Vielfalt potenzieller Datenquellen zu betrachten, wie den Prozess, den wir Monitoring nennen.
Observability arbeitet auf die gleichen Ziele hin und nutzt eine Vielzahl von Datenquellen. Logs, Metriken und Traces sind vielleicht die gebräuchlichsten, aber beschränken Sie sich nicht allein darauf. Verwenden Sie diejenigen Säulen der Observability, die basierend auf der Anwendungsarchitektur Ihres Unternehmens, der Hosting-Umgebung und den Prioritäten der Endbenutzer das beste Ergebnis für Sie liefern.
