In klassischen Architekturen, wie bspw. monolithischen Systemen, reichte oft ein Blick in die Log-Datei des Systems um erkennen zu können, ob das System sich wie erwartet verhält. Falls nicht konnte so auch festgestellt werden, warum sich das System nicht wie erwartet verhält.
Es reichte also oftmals ein Tool, dass es verstand Log-Dateien entsprechend zu interpretieren. Dieser Umstand gilt jedoch nicht mehr für die cloud-nativen Architekturen die heutzutage zum Einsatz kommen. Zu verteilt sind moderne Systeme und somit auch die Log-Dateien, als das sie sinnvoll mit traditionellen Mitteln in einen Zusammenhang gestellt werden können.
Der Observe Zwischenstopp kümmert sich genau um diesen Umstand und transformiert das klassische Monitoring in eine Observability-First Strategie.
Was kann ich mir von diesem Zwischenstopp erwarten?
Im Observe-Zwischenstopp sind folgende Themen enthalten:
Visualisierung & Alerting
Application Performance Monitoring
Infrastructure Monitoring
SIEM
Kostenüberwachung
Observability ist natürlich weitaus mehr, als das betrachten von Log-Dateien. Unterschiedliche Signale wie Traces, Metriken oder Logs müssen in Verbindung gebracht werden, um ein ganzheitliches Bild der Lage zu erhalten. Das Monitoring-Backend kann dann entsprechend automatisch Ausnahmesituationen erkennen und darauf zu reagieren.
Als CNCF Silber Member bauen wir unsere Lösung dazu natürlich auf Standards aus der CNCF Landkarte auf. Zum Thema Observability hat sich in den letzten Jahren OpenTelemetry als Standard etabliert und ist mittlerweile zu einem der größten Projekte innerhalb der CNCF gereift.
OpenTelemetry integriert die genannten Signale im Standard und ermöglicht diese miteinander zu korrelieren. Um verteilte Systeme Ende-zu-Ende überwachen zu können bedient es sich dabei dem W3C Trace Context-Standard und erfindet somit das Rad nicht neu.
Auch fachliche Informationen können auf standardisierten Weg über mehrere Teilsysteme hinweg propagiert werden, was es zum Beispiel ermöglicht, Service Level Objectives auf derartige Informationen aufzubauen. Dazu baut OpenTelemetry auf dem W3C Baggage-Standard auf.
Dank einer standardisierten API und eines herstellerunabhängigen SDKs kann mit den Telemetriedaten direkt im Applikationscode interagiert werden. Das ermöglicht eine zusätzliche Ebene für die Aggregation von Telemetriedaten und dadurch natürlich ganz neue Möglichkeiten bei der Auswertung dieser Daten.
Warum soll ich bei diesem Zwischenstopp halt machen?
Dieser Zwischenstopp ist essentiell um die nachfolgenden Punkte in einem cloud nativen System nachhaltig und langfristig abdecken zu können:
Einführung von (Near-)Realtime Alerting & AI Ops
Das Verhalten des Gesamtsystems verstehen
Überwachung von Sicherheits-relevanten Ereignissen
Überblick zu den Betriebskosten erhalten
Wie läuft dieser Zwischenstopp ab?
Wir haben ein Vorgehensmodell entworfen, dass die Einführung von OpenTelemetry so friktionsfrei wie möglich macht, indem wir iterativ in unserer bewährten CRAWL-WALK-RUN-Methode Themengebiete, an die Kundenbedürfnisse angepasst, bearbeiten:
Der aktuelle Hauptcontributor zum Herzstück einer Observability-Architektur auf Basis von OpenTelemetry - nämlich zum Collector - ist Splunk. Splunk dürfte vielen vermutlich ein Begriff rund um das Thema Logging oder SIEM sein, doch auch im Application Performance Monitoring und Infrastructure Monitoring Bereich ist man mittlerweile sehr stark mit der Splunk Observability Cloud aufgestellt.
Im nächsten Beitrag werden wir daher näher auf dieses Produkt unseres Partners eingehen, da es eine optimale und native Untersützung für OpenTelemetry bietet und auch hinsichtlich Usability neue Akzente setzt, welche ideal auch zur DevOps-Philosophie passen.
Comments