Im traditionellen Monitoring von Applikationen und Infrastruktur wurden Telemetriedaten wie Logs, Metriken und Traces von unterschiedlichen, ganz spezifischen Backends verarbeitet und für Problemanalysen aufbereitet.
Jedes dieser Backends hatte oftmals eigene proprietäre Agents notwendig gemacht, um eine Applikation oder Infrastruktur zu überwachen. Aus Applikationsentwickler-Sicht war es so nicht möglich, im Applikationscode dynamisch bspw. fachliche Metriken zu setzen (und so noch gezieltere Analysen zu ermöglichen), da ein Provider-Lockin direkt im Source Code nicht zielführend ist.
Folgende Übersicht skizziert traditionelles Monitoring von Applikationen und Infrastruktur:
Ein weiterer großer Nachteil dieser Architektur ist, dass es nicht oder nur mit großen Aufwand möglich ist, die unterschiedlichen Telemetriedaten miteinander zu korrelieren und so ein umfassendes Bild, zum Zustand der eignen Applikation/Infrastruktur, zu erhalten.
Die Business Herausforderung:
Organisationen überwachen Teile der Infrastruktur separat was zu isolierten Datensilos führt. Durch fehlende Korrelation wird die Ursache nicht oder nicht schnell genug gefunden.
OpenTelemetry
OpenTelemetry tritt an, um diese Probleme zu lösen. Seine Ursprünge hat es im OpenTracing und OpenCensus Projekt und es ist mittlerweile eines der am aktivsten entwickelten Projekte im CNCF Umfeld.
OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.
OpenTelemetry selbst baut wiederum auf offenen Standards, wie bspw. der W3C Trace Context oder der W3C Baggage Spezifikation auf.
Ein grundsätzlich optionale, aber doch sehr wesentliche Komponente ist der OpenTelemetry Collector. Dieser ermöglicht einen herstellerunabhängigen Empfang, Verarbeitung und Weiterleitung von Telemetriedaten. Von uns gibt es daher eine klare Empfehlung diese Komponente in der eigenen Observability-Architektur einzusetzen.
Das folgende Schaubild skizziert eine mögliche Architektur:
Splunk Observability Cloud
Say goodbye to blind spots, guesswork and swivel-chair monitoring with all of your metrics, logs and traces automatically correlated in one place.
Den meisten wird Splunk ein Begriff durch das mächtigste Tool zum Verarbeiten und Aufbereiten von Logs sein, nämlich Splunk Core. Doch mittlerweile bietet Splunk ein weitaus größeres Produktportfolio. Die einzelnen Produkte werden über die Splunk Platform miteinander verbunden und erlauben so aus Kundensicht größtmögliche Flexibilität bezüglich Funktionalität aber auch zu Lizenzierungsmöglichkeiten.
Eines der Produkte der Splunk Platform ist die Splunk Observability Cloud (O11y Cloud), welche ein natives OpenTelemetry Backend ist. Dank der nativen OpenTelemetry Unterstützung gehören proprietäre Agenten der Vergangenheit an. Splunk bietet auch eigene Distributionen der OpenTelemetry Agents/Profiler und dem OpenTelemetry Collector an, sodass auch Enterprise Support für diese Komponenten im Lizenzumfang enthalten ist.
Weiters glänzt die O11y Cloud mit einer niedrigen Einstiegshürde und einer flachen Lernkurve. Das ist auch eine wesentliche Abgrenzung zu Splunk Core. Splunk Core bietet eine extrem mächtigte Query Language, benötigt jedoch mehr Aufwand bei der Einarbeitung. Die O11y Cloud kommt bereits im Standardumfang mit vielen vorgefertigen Dashboards und einer idealen User Experience für DevOps Teams. Die Tools ergänzen sich damit perfekt.
Viele Bereiche der Splunk Observability Cloud können außerdem via Terraform mit dem Splunk Observability Cloud Terraform Provider automatisiert eingerichtet werden. Damit lässt sich Observability optimal in CI/CD integrieren und echtes "Shift Left" ermöglichen.
Das folgende Beispiel gibt abschließend einen Überblick, wie Telemetriedaten in der O11y Cloud in Verbindung gebracht werden und wie mit wenigen User-Interface Interaktionen eine Root-Cause-Analyse durchführt wird.
Von der Metrik zur Fehlerursache
In der Regel startet die Problemanalyse indem ein Alert ausgelöst wurde, weil eine Metrik einen Grenzwert unter- bzw. überschritten hat. Die Bestimmung von Grenzwerten sowie die korrekte Einordnung ob es sich tatsächlich um eine Ausnahmesituation handelt, erfolgt in der O11y Cloud natürlich KI-gestützt.
Das klassische Bild des Eisbergs ist für die Root-Cause-Analyse dabei sehr passend. Wobei dazu anzumerken ist, dass aus unserer Sicht Logs heutzutage nur noch der letzte "Anker" sind um eine Problemursache zu lokalisieren. Sind Tracing und Metriken gut aufgesetzt, reicht oft der Blick in einen Trace um die Ursache des Problems zu erkennen.
Steigt man direkt in den Application Performance Monitoring (APM) Menüpunkt der O11y Cloud ein, erhält man bereits Übersichten zu diversen Metriken im zeitlichen Verlauf. Im gezeigten Beispiel ist eine Hohe Latenz beim printing-service zu erkennen. Mit einem Klick in das Diagramm, öffnet sich umgehend ein Pop-Up mit welchen man direkt in zugehörige Traces navigieren kann:
Bereits im Pop-Up ist ersichtlich, dass die O11y Cloud ein Problem erkannt hat. In der Detailansicht zum Trace, wird die Ursache des Problems sofort nachvollziehbar (das author-service liefert einen Server-Fehler):
Beachtenswert ist noch der untere Bereich des Screenshots. Über die Buttons "Infrastructure" und "Logs" kann direkt ins Infrastruktur Monitoring oder in den Log Observer verlinkt werden. Dieses Feature wird Related Content genannt und trägt dank der Korrelation der unterschiedlichen Telemetriedaten wesentlich zur effizienten Problemanalyse bei.
Verlinkt man zum Infrastruktur Monitoring erhält man sofort eine Übersicht zu den Nodes auf welchen das printing-service läuft. In dieser Übersicht kann nun bis auf Container-Ebene "gezoomt" werden. So kann zu jeder Infrastrukturebene gezielte und detaillierte Informationen abgerufen werden.
Verlinkt wiederum in den Log Observer, wird automatisch eine Suche mit der entsprechenden Trace-ID gestartet. Damit werden sämtliche Log-Einträge zur Trace-ID über alle beteiligten Services hinweg dargestellt.
Die Business Herausforderung:
Organisationen überwachen Teile der Infrastruktur separat was zu isolierten Datensilos führt. Durch fehlende Korrelation wird die Ursache nicht oder nicht schnell genug gefunden.
Unsere Lösung:
Observability integriert Monitoring-Daten aus verschiedenen Quellen Probleme werden schnell zu isoliert und die Ursache effizient identifiziert.
Um beim Bild des Eisbergs zu bleiben: Das skizzierte Beispiel streift nur einen kleinen Teil der Möglichkeiten der O11y Cloud. Im Zuge von Demo-Sessions präsentieren wir sehr gerne ausführlich weitere Funktionen der O11y Cloud 🚀
Comentários