Observability

Was sind die Unterschiede zwischen Monitoring und Observability?

Die Konzepte von Monitoring und Observability sind miteinander verwandt, aber die Beziehung ist komplex. Zu den Unterschieden gehören die folgenden Aspekte:

• Monitoring Tools sammeln passiv Informationen, von denen sich die meisten als nicht besonders wichtig erweisen. Dies kann dazu führen, dass das operative Personal und sogar KI-Tools (künstliche Intelligenz) in Daten ertrinken. Observability sammelt aktiv Daten, um sich auf das zu konzentrieren, was relevant ist, zum Beispiel die Faktoren, die operative Entscheidungen und Maßnahmen treiben.
• Beim Monitoring werden in der Regel Informationen aus verfügbaren Quellen wie Management Information Bases (MIB), Application Programming Interfaces (API) und Log-Protokolle erfasst. Observability nutzt zwar auch diese Quellen, fügt aber oft spezifische neue Informationszugänge hinzu, um wichtige Daten zu sammeln.
• Monitoring konzentriert sich auf die Infrastruktur, während Observability in gleichem Maße Anwendungen einbezieht. Folglich erstreckt sich Observability oft auch auf Workflows, während Monitoring sich auf punktuelle Beobachtungen konzentriert.
• Die per Monitoring zur Verfügung gestellten Daten sind häufig das einzige erwartete Ergebnis. Observability setzt voraus, dass Datenquellen zu einem Analyseprozess beitragen, der den Zustand einer Anwendung oder eines Systems optimal darstellt.

Warum ist Observability wichtig?

Seit Jahrzehnten haben Unternehmen, die komplexe verteilte Systeme überwachen und von ihnen abhängig sind, mit Problemen zu kämpfen, deren Ursachen meist in einer Flut irrelevanter Daten verborgen sind. Oder es kommt zu Problemen mit allgemeinen Symptomen der zugrunde liegenden Probleme. Der Ansatz der Root-Cause-Analyse hat sich aus diesem Problem heraus entwickelt, ebenso wie der heutige Schwerpunkt auf Observability. Durch den Fokus auf die Zustände eines Systems und nicht auf den Zustand der einzelnen Systemelemente bietet Observability einen besseren Aufschluss über die Funktionalität des Systems und dessen Eignung, seine Aufgabe zu erfüllen. Außerdem ermöglicht sie ein optimales Benutzer- und Kundenerlebnis.

Observability ist gegebenenfalls proaktiv, das heißt, sie umfasst Techniken, um Sichtbarkeit in Bereichen zu ergänzen, in denen sie möglicherweise fehlt. Darüber hinaus ist sie reaktiv, indem sie vorhandene kritische Daten priorisiert.

Observability kann zudem Rohdaten mit nützlicheren IT-Zustands-Kennzahlen verknüpfen, etwa mit Key Performance Indicators (KPI), bei denen es sich um eine Zusammenfassung von Zuständen handelt, um die allgemeine User Experience (UX) und Anwenderzufriedenheit darzustellen.

Was sind die drei Datenformate der Observability?

Die drei primären Quelldatentypen für Observability sind Log-Protokolle (auch Logs genannt), Metriken und Traces. Sie werden auch als die drei Säulen der Observability bezeichnet.

• Bei Metriken handelt es sich um operative Echtzeitdaten, auf die typischerweise entweder über eine API (eine Pull- oder Polling-Strategie) oder als generiertes Ereignis beziehungsweise Telemetrie (eine Push-Benachrichtigung) zugegriffen wird. Da sie ereignisgesteuert sind, werden die meisten Aufgaben des Fehlermanagements von Metriken gesteuert.
• Log-Protokolle sind Aufzeichnungen von Ereignissen, in der Regel in textlicher oder von Menschen lesbarer Form. Sie werden fast immer von Infrastrukturelementen, wie Netzwerkgeräten und Servern, generiert. Sie können zudem von Plattform-Software, etwa Betriebssystemen und Middleware, erstellt werden. Einige Anwendungen protokollieren das, was der Entwickler als kritische Informationen betrachtet. Log-Informationen sind im Allgemeinen vergangenheitsbezogen oder retrospektiv und werden oft verwendet, um den Kontext im Operations Management Es gibt jedoch Log-Protokolle, die Sammlungen von Ereignissen oder Telemetriedaten darstellen, und die detaillierten Informationen können in Echtzeit zur Verfügung stehen.
• Traces sind Aufzeichnungen von Informationspfaden oder Workflows, die dazu dienen, eine Arbeitseinheit, zum Beispiel eine Transaktion, durch die einzelnen Prozesse zu verfolgen, die die Anwendungslogik vorgibt. Da die Arbeitssteuerung normalerweise von der Logik der einzelnen Komponenten oder von Steuerungs-Tools wie Servicebussen oder Meshes abhängt, ist ein Trace ein indirekter Weg, um die Logik einer Anwendung zu bewerten. Einige Trace-Daten können durch Workflow-Prozesse, etwa Servicebusse oder Cloud-native Microservices und Service-Meshing, zur Verfügung stehen. Es kann allerdings notwendig sein, Trace Tools in den Softwareentwicklungsprozess einzubinden, um vollständige Transparenz zu erhalten.

In einigen Situationen reichen die drei Säulen der Observability nicht und es müssen weitere Datenquellen und Methoden berücksichtigt werden.

Was sind die Vorteile von Observability?

Der Hauptvorteil von Observability liegt in der Verbesserung der User Experience, indem man sich bei den operativen Aufgaben auf Probleme konzentriert, die das Nutzererlebnis gefährden. Die ordnungsgemäße Anwendung von Observability kann die Verfügbarkeit und Performance von Anwendungen optimieren.

Observability-Methoden reduzieren normalerweise auch die Betriebskosten, indem sie das Handling von schwierigen Situationen erleichtern. Dies geschieht durch eine Verringerung der Menge an irrelevanten oder redundanten Informationen und durch die Priorisierung der Benachrichtigung über kritische Ereignisse. Diese Verbesserungen machen sich vor allem in großen Unternehmen bemerkbar, wo große Operations-Teams erforderlich sind.

Einige Nutzer berichten, dass Observability-Methoden Informationen liefern, die für das Zuverlässigkeits- und Performance-Management sowie sogar für das Infrastrukturdesign und die Tool-Auswahl hilfreich sind. Dies liegt daran, dass die Konzentration auf wirklich kritische Informationen dazu beiträgt, Schwachstellen zu erkennen, die sich durch die Änderung von Konfigurationen, des Anwendungsdesigns und der Ressourcenausstattung beheben lassen.

Was sind die Herausforderungen von Observability?

Observability bringt auch Herausforderungen mit sich, unter anderem die folgenden Punkte:

• Unbeabsichtigte Nichtsichtbarkeit wichtiger Ereignisse und Daten, weil Datenquellen, die um Aufmerksamkeit konkurrieren, nicht richtig gefiltert oder strukturiert wurden. Das kann dazu führen, dass ein kritischer Zustand übersehen wird, weil er nicht angezeigt oder verarbeitet werden kann.
• Fehlende Quelldaten, insbesondere Trace-Informationen. Nicht alle wichtigen Informationen werden erfasst, besonders auf Anwendungsebene und in Bezug auf das Tracing von Workflows. Im Gegensatz zum Ressourcen- oder Komponentenstatus erfordert die Verfolgung von Workflows üblicherweise spezielle Softwareanpassungen, um das Tracing zu ermöglichen.
• Mehrere Informationsformate aus verschiedenen Quellen des gleichen Informationstyps können es erschweren, die richtigen Informationen zusammenzustellen und die verfügbaren Daten zu interpretieren. Eine systematische Strategie zur Strukturierung von Informationen in einer Standardform ist notwendig, um einen optimalen Umgang mit Observability zu gewährleisten.

Wie lässt sich Observability implementieren?

Observability beginnt mit einem Plan, geht dann über zu einer Architektur und schließt mit einer Observability-Plattform ab. Es ist wichtig, diesem Ansatz zu folgen, da sonst das Risiko von Schwierigkeiten und Problemen steigt.

Am Anfang eines Observability-Plans steht die Identifizierung der gewünschten spezifischen Vorteile. Dann wird jeder Vorteil mit einer Beschreibung der Daten verknüpft, die erforderlich sind, um den Plan zu realisieren. Es ist zwar wichtig, dass diese Datenverknüpfung die verfügbaren Daten aus Monitoring und Telemetrie berücksichtigt. Aber ebenso wichtig ist es, relevante Informationen zu ermitteln, die aktuell nicht erfasst werden – oder in einem System erfasst werden, das seine Daten nicht für die Observability-Analyse bereitstellt.

Die Observability-Architektur ist eine Diagrammdarstellung der Beziehung zwischen den Quelldaten und der Präsentation der Daten für das operative Personal, KI- und Machine-Learning-Systeme etc. Alle Datenquellen müssen identifiziert werden, zusammen mit den Informationen, die jede Quelle beitragen soll. Über den Datenquellen sollte das Diagramm die Tools zur Erfassung und Darstellung der Informationen, die Auswahl der Tools für die Analyse und Filterung der Daten sowie die Tool-Auswahl für die Datenpräsentation aufführen. Es gibt für Monitoring und Observability sowohl proprietäre als auch Open Source Tools. Es empfiehlt sich, die Optionen zu dokumentieren, die für die spezifischen Zielmissionen geeignet sind.

Der letzte Schritt bei der Implementierung ist ein spezifisches Observability Toolkit oder eine Observability-Plattform. Der Unterschied zwischen beiden kann sehr subtil sein:

• Ein Toolkit umfasst verschiedene Monitoring Tools oder Überwachungsfunktionen, die sich zur Unterstützung von Observability eignen. Doch sie sind auf eine manuelle Bedienung oder eine separate Softwareschicht angewiesen, um eine Kollektivanalyse zu unterstützen. Ein Toolkit-Ansatz erfordert in der Regel erhebliche Anpassungen, kann aber vorhandene Software und Datenquellen einbinden.
• Eine Observability-Plattform ist eine integrierte Softwareanwendung, die Informationen erfasst, Analysen inklusive KPI-Ableitungen durchführt und den operativen Nutzern brauchbare Ergebnisse liefert. Eine Plattform muss möglicherweise noch angepasst werden, um alle verfügbaren Datenquellen zu berücksichtigen. Zudem kann sie die Art und Weise der Datenintegration einschränken.

Der Nutzen von Observability hängt davon ab, dass man diese drei Implementierungsschritte auf strukturierte Weise durchführt. Werden sie übersprungen oder nur halbherzig umgesetzt, ist das Konzept – und die Investition dafür – gefährdet.