Interview mit IBM – Was ist der Unterschied zwischen Monitoring und Observability?

In der IT-Welt wird Monitoring und Observability häufig synonym verwendet. Allerdings gibt es gravierende Unterschiede und selbst bei der Observability gibt es unterschiedliche Ausrichtungen. Netzpalaver sprach via Remote-Session mit Georg Ember, Senior IT Architect and Brand Technical Specialist, AIOPs and Automation, IBM Technology, DACH, darüber welche Unterschiede es beim Monitoring und Observability gibt, deren Einsatzgebiete und welche Trends sich bei der Observability abzeichen.

#Netzpalaver

#IBM

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube immer entsperren

PHA+PGlmcmFtZSB0aXRsZT0iSW50ZXJ2aWV3IG1pdCBJQk0gLSBXYXMgaXN0IGRlciBVbnRlcnNjaGllZCB6d2lzY2hlbiBNb25pdG9yaW5nIHVuZCBPYnNlcnZhYmlsaXR5PyIgc3JjPSJodHRwczovL3d3dy55b3V0dWJlLW5vY29va2llLmNvbS9lbWJlZC9WNTdRLTljcjZqZyIgd2lkdGg9IjY0MCIgaGVpZ2h0PSI0MDAiIGZyYW1lYm9yZGVyPSIwIiBhbGxvd2Z1bGxzY3JlZW49ImFsbG93ZnVsbHNjcmVlbiI+PHNwYW4gZGF0YS1tY2UtdHlwZT0iYm9va21hcmsiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmUtYmxvY2s7IHdpZHRoOiAwcHg7IG92ZXJmbG93OiBoaWRkZW47IGxpbmUtaGVpZ2h0OiAwOyIgY2xhc3M9Im1jZV9TRUxSRVNfc3RhcnQiPu+7vzwvc3Bhbj48L2lmcmFtZT4=

Fragen:

0:05 Was ist der Unterschied zwischen Monitoring und Observability?

1:32 Welche Arten von Observability gibt es?

2:49 Welche Nuancen bzw. Unterschiede sind beim Synthetic-Monitoring und bei der Real-Time-Observability ausschlaggebend?

4:40 Welche Rolle spielt in diesem Umfeld das „distributed tracing“?

6:34 Open-Telemetry wird als Standard immer poplulärer. Wie bereichert dieser Standard die Observability?

7:57 Welche Trends zeichnen sich bei Observability und Application-Performance-Management ab?

• Observability und Monitoring sind technisch verwandt, aber arbeiten mit unterschiedlichen Zielen. Aber Ohne Monitoring gibt es keine sinnvolle Observability !
• Monitoring bietet einen grundlegenden Einblick in ein System oder Anwendung und macht die Erfassung von Daten über Leistung, Verfügbarkeit, Nutzung, und identifiziert Probleme.
• Monitoring ist die Überwachung von Echtzeitdaten, und erfolgt mit spezieller Agenten, die Daten aus verschiedenen Quellen, z.B. aus dem Netzwerk oder aus Anwendungen, sammelt und visualisiert, also eine Echtzeitanalyse und Echtzeitdarstellung der gemessenen Telemetrie-Daten.
• Bei der Observability geht es darüber hinaus um den ganzheitlichen Blick, mit dem Ziel, Gesamtleistung und Gesamt-Zuverlässigkeit zu verbessern, gerade in verteilten oder lose gekoppelten Architekturen, um somit die  zusammen-hängenden Informationen zu verstehen und diese Zusammenhänge detaillierter zu analysieren, also die Gründe für diese Datenlage zu finden.
• Daher wird Observability wird oft bereits in frühen Software- und Anwendungsentwicklung angewendet.
• Es geht darum komplexe Softwaresysteme frühzeitig in der Entwicklungskette zu überwachen und frühzeitig zu optimieren.
• In einem frühen Stadium können Entwickler und Administratoren Probleme in der Software meist eher identifizieren und beheben. Das passiert oft mit synthetischem Monitoring.

• Im IT Markt gibt es mittlerweile viele Arten und Begriffe für Observability, je nach Sichtweise und Anwendungsbereich.
• Cisco und Dynatrace nennen es gerne Full Stack Observability. IBM nennt es Automated Observability. Gartner definiert das Thema Observability als Trendtechnologie, besonders die Variante ”Applied Observability”
• Andere Hersteller fügen den AI Bezug dazu und nennen es AI driven Observability
• Applied Observability ist die angewandte Nutzung von beobachtbaren Daten in einem hochgradig orchestrierten und integrierten Ansatz über Geschäftsfunktionen, Anwendungen sowie Infrastruktur- und Betriebsteams hinweg. 
• Observability ist keine einzelne Technologie oder eine bestimmte Nische. Sie erstreckt sich über viele Systeme, Anwendungen und Umgebungen und Schichten der Organisation.
• Egal welche Observability, es ist die Fähigkeit zu verstehen, was in einem Gesamt-System vor sich geht, basierend auf den gesammelten externen Daten, die von den jeweiligen Systemen und Anwendungen veröffentlicht werden.
• Observability bringt dann etwas, wenn verwertbare Daten, wie Logs, Metriken und Traces aus verschiedenen Quellen angemessen verbunden, optimiert und kontextbezogen analysiert werden. 
• Observability wird oft und gerne mit Monitoring gleichgesetzt, aber es ist viel mehr.

• Synthetic-Monitoring ist eine Methode, bei der man die Interaktion von Anwendern mit einem System simuliert.
• Dabei sammelt und analysiert man die Daten aus den simulierten Interaktionen. Man projeziert, wie sich die Anwendenden verhalten und wie das System auf die Eingaben und Aktionen der User oder Jobs reagiert.
• Synthetic-Monitoring wird auch als pro-aktives Monitoring bezeichnet, da nicht auf Ereignisse gewartet wird, sondern es werden gezielt Szenarien simuliert, um zu überprüfen, wie sich das Gesamt-System verhält.
• Aktives Monitoring ist ein prädiktiver Ansatz, indem potenzielle Probleme durch Projezieren aufgezeigt werden, bevor sie sich auf die Endbenutzer auswirken.
• Real-time Observability ist eine Methode, wo über Passives Beobachten die Daten aus tatsächlichen Transaktionen in Echtzeit gesammelt werden, d.h. man lauscht in Echtzeit, was da so an Telemetrie Daten reinkommt.
• Im Gegensatz zu Synthetic Monitoring sammelt passives Beobachten tatsächliche in Echtzeit kommende Benutzerdaten.  Man sammelt passiv und generiert größere Mengen an Leistungsdaten als aktives synthetisches Monitoring, denn bei synthetischem Monitoring wird mehr simuliert.
• In der Praxis kommen aber beide Arten zusammen. Ein ideales Monitoring umfasst somit beide Aspekte, sowohl synthetisches proaktives prädiktives Monitoring als auch passives Real-Time Observability.
• Nur beide Konzepte zusammen bieten eine 360-Grad Observability Sicht auf die Systeme und Anwendungen.

• Tracing überprüft, wie sich eine Anwendung in ihren Transaktionen verhält.
• Tracing liefert einen Bericht, der den Ablauf einer Anfrage von Anfang bis Ende verzeichnet, idealerweise end-to-end.
• Distributed Tracing kann – gerade bei komplexen und lose gekoppelten Service Anfragen, wie bei Microservices üblich, durch jeden Service gehen und jedes Modul in jedem Schritt verfolgen.
• Das übliche Tracing stößt jedoch beim Troubleshooting von Anwendungen gerade in verteilten Software-Architekturen an seine Grenzen.
• Viele Observability Produkte arbeiten mit tracing, aber das kostet eben viele Systemresourcen. Um den Tracing Aufwand zu reduzieren, werden dann die Daten oft “gesampelt”, man verwendet also ein sampling.
• Beim Sampling, auch downsampling werden die Signale reduziert, die man beim tracing einsammelt, Man sammelt beim sampling nur z.B. jeden 100sten request statt jeden request, um zu sehen, wie sich eine Anwendung verhält. Man erwartet, dass man mit weniger tracing Daten die gleichen Erkenntnisse bekommt. Muss nicht immer sein, aber kann oft sein.
• Beim Sampling gibt es Vorteile und Nachteile, genau so wie Befürworter, und auch Kritiker.
• Es ist eben eine Philosophie Frage, weil intensives tracing auch zusätzliche Systemresourcen, evtl. auch Lizenzen und damit mehr Geld kostet und mit sampling diese zusätzlichen Aufwände reduziert werden können.
• Ein Verfechter von Sampling Verfahren ist z.B. OpenTelemetry, auch Otel genannt, weil bei Otel ziemlich viele Daten entstehen.

• OpenTelemetry ist ein Open-Source-Projekt und ein mittlerweile wichtiger und auch weit verbreiteter offener Standard für die Sammlung von Logs, Traces und Metriken. 
• Otel ist auch ein offener Standard für die Instrumentierung von Services und eine einheitliche Methode zur Performance-Daten-Ermittlung und Messung. 
• Ziel von Otel ist die Vereinheitlichung bei der Erfassung und des Versands von Telemetriedaten an eine Backend-Observability-Plattform. 
• Dazu wird ein zentraler Collector Service definiert, mit dem Telemetriedaten aus Anwendungen und Services erfasst werden können, sowie ein Exporter zum Versand dieser Daten an die Observability-Plattform Ihrer Wahl.
• Otel hat wesentliche Vorteile : Einheitliche Observability, Innovation in der Community, eine kontinuierliche Optimierung des Observability-Frameworks,
• Gerade durch die Standardisierung sind die Konsistenz und Kompatibilität bei der Observability von Anwendungen und Services stets gewährleistet. Man erhält einheitliche Daten, auf einheitlichem Weg und in einem einheitlichen Format. 
• Otel – erst war es ein Trend aus der Monitoring Community, jetzt ist es ein verbreiteter Standard bei der Observability.

• Ein wesentlicher Trend ist die Standardisierung, wie gerade erwähnt, also immer mehr Einsatz von Otel.
• Entweder ich instrumentiere meine Anwendungen mit Otel, und sende diese über einen Otel collector an mein Observability backend oder man greift die Daten per API ab, d.h. ich benötige dann keine Agenten, die ich multipel ausrollen muss.
• Eins sollte aber klar sein :  Mit Agenten bekomme ich oft mehr und detailliertere Informationen als ohne Agenten. 
• Dann etablieren sich auch zwei Datenhaltungsarchitekturen im Umfeld der Observability :
• Einmal Im Observability Produkt selbst, mit eigener Datenhaltung, oder gesammelt und abgelegt in einem seperaten, zentralen Data Lake, z.B. Elastic oder Grafana Cloud, usw.
• Der unübersehbarste Trend überhaupt ist die Einbindung von KI. Dabei gibt es zwei Arten :
• KI Algorithmen für Erkennung von Telemetrie Mustern, oder Anomalien Erkennung, oder mit KI die automatisierte Behebungen von erkannten Problemen. Hier greift man dann auf generative KI zurück.
• Die Integration mit genAI Systemen kann helfen, aus riesigen Telemetrie Datenmengen die richtigen Erkenntnisse zu ziehen, oder Workflows zur Problembehebung vorzuschlagen, oder eine Qualitätsicherung bei der Problembehebung zu unterstützen, sowie Trends bei der kontinuierlichen “Beobachtung” / Observability zu erkennen. 
• Es bleibt also spannend, wie gut sich KI im Bereich Observability durchsetzen wird. Dass es sich durchsetzen wird, ist klar. Aber wie gut, und wie hilfreich, werden wir bald sehen. Weil es kostet ja auch viele zusätzliche Systemresourcen. Das darf man nicht unterschätzen. Nutzen vs. Aufwand vs. Kosten.