Drei Säulen der Observability: Protokolle, Metriken und Traces

Viele Regierungsstrukturen und Gremien stützen sich auf drei Säulen, um den Erfolg sicherzustellen. Die Praktiken der Corporate Responsibility konzentrieren sich auf ökologische, soziale und finanzielle Nachhaltigkeit, um ihre Geschäftspraktiken zu leiten. 

Unternehmen, die eine digitale Transformation durchführen möchten, nutzen bei der Umstellung häufig drei Säulen: Menschen, Prozesse und Technologie. Dieses Framework ermutigt Entscheidungsträger, sich auf die Bindung kreativer, kooperativer Technik-Experten (Menschen) zu konzentrieren, strukturierte und sorgfältige Datenverwaltung und Sicherheitspraktiken (Prozesse) zu verwenden und sich auf fortschrittliche Tools und Plattformen zu verlassen, um Fortschritte zu erzielen. 

Und die drei Säulen, auf denen Scrum basiert – ein Satz von Framework und Prinzipien, die flexibles Projektmanagement ermöglichen – sind Transparenz, Überprüfung und Anpassung. In jedem dieser Fälle sind die Säulen unterschiedlich und wichtig, aber unvollständig. Jeder von ihnen hat seinen eigenen Handlungsspielraum und seine eigenen Prioritäten, doch ihre wahre Stärke liegt in der Art und Weise, wie sie zusammenarbeiten und interagieren, um größere Ziele zu unterstützen. Observability ist nicht anders.

In einem IT-Kontext nutzt Observability drei Säulen von Telemetriedaten – Metriken, Protokolle und Traces –, um riesige Computernetzwerke leichter zu visualisieren und zu verstehen. Es ermöglicht Entwicklern, den internen Zustand eines Systems anhand seiner externen Outputs zu verstehen. Wenn ein Netzwerk beobachtbar ist, kann das IT-Personal die Ursache einer Leistung anhand der von ihm erzeugten Daten und ohne zusätzliche Tests oder Codierung ermitteln.

Observability-Lösungen verwenden die rohen Ausgabedaten eines Systems, um Datenanalysen durchzuführen. So erhalten Teams die durchgängige Netzwerktransparenz und verwertbare Erkenntnisse, die sie für eine effektive Fehlersuche und -behebung benötigen.

Beobachtbare Architekturen helfen Entwicklungsteams und Netzwerkadministratoren, die Komplexität moderner Computernetzwerke zu bewältigen. Heutzutage bedeutet das, riesige, hochdynamische Computing-Netzwerke zu unterhalten, die oft Hybrid-Cloud- und Multicloud-Konfigurationen sowie eine Reihe von cloudnativen Anwendungen, Microservices und Kubernetes-Containern umfassen.

Observability-Tools, wie die Open-Source-Lösung OpenTelemetry, bieten Unternehmen einen umfassenden, kontextualisierten Überblick über den Systemzustand. Full-Stack-Visualisierung hilft Teams, anomale Datenmuster und Leistungsengpässe zu erkennen, bevor sie sich auf die Endbenutzer auswirken. So kann die Observability Unternehmen dabei helfen, Ausfallzeit im Netzwerk zu minimieren und die Zuverlässigkeit ihrer Services in verschiedenen Anwendungsfällen aufrechtzuerhalten.

Unabhängig von der Komplexität des Netzwerks hängt die Observability jedoch von System-„Ereignissen“ und seinen drei Grundpfeilern ab. Die Säulen ermöglichen es Observability-Plattformen, Daten aus Frontend-Anwendungen, Backend-Services, CI/CD-Pipelines und Streaming-Daten-Pipelines, die über verteilte Systeme laufen, zu sammeln und zu analysieren.

Observability erfordert eine sorgfältige Datenerfassung von jeder Komponente eines Netzwerks, um das „Was“, „Wo“ und „Warum“ von Systemereignissen zu bestimmen und zu klären, wie sich Ereignisse auf die Observability der gesamten Architektur auswirken können. Daher sind Ereignisse die Grundlage für Überwachung und Telemetrie.

Ereignisse sind eindeutige Vorkommnisse in einem Netz, die zu bestimmten Zeiten stattfinden und in der Regel wertvolle Daten für Protokolle, Metriken und Traces liefern, wodurch sie für die Observability ebenso wichtig sind wie die drei Säulen. Ereignisse existieren in einem breiteren Kontext.

Wenn zum Beispiel ein Client Ressourcen von einem Unternehmensserver anfordert, leitet der Client die Anfrage an den entsprechenden API-Endpunkt weiter, indem er die URL des API-Endpunkts verwendet. Der Server empfängt die Anfrage, prüft sie auf Zugangsdaten (z. B. einen API-Schlüssel) und Clientberechtigungen und verarbeitet sie, vorausgesetzt, diese sind gültig, gemäß den Spezifikationen der API(z. B. dass die Antwort richtig formatiert ist). Der Server sendet dann eine Antwort mit den angeforderten Daten an den Client zurück.

Ereignisse lösen zu bestimmten Zeitpunkten unterschiedliche Aktionen aus. Observability-Tools verlassen sich also darauf, dass sie die Tracking-, Analyse- und Korrelationsprozesse einleiten, die DevOps-Teams dabei helfen, ihre IT-Umgebungen zu visualisieren und ihre Netzwerke zu optimieren.

Metriken bieten quantitative Einblicke in die Systemleistung, indem sie verschiedene Netzwerkparameter messen. Sie helfen Teams, das „Was“ von Systemproblemen zu verstehen. Zu den Arten von Metriken gehören:

• Host-Metriken: Speicher-, Festplatten- und CPU-Auslastung
• Netzwerkleistungsmetriken: Betriebszeit, Latenz, Durchsatz
• App-Metriken: Antwortzeiten, Anfrage- und Fehlerraten
• Serverpool-Metriken: Gesamtinstanzen, Anzahl der laufenden Instanzen
• Externe Abhängigkeitsmetriken: Verfügbarkeit, Servicestatus

Gängige Metriken – wie Speichernutzung und Latenz – stimmen intuitiv mit dem Systemzustand überein. Allerdings können auch viele andere Metriken und Key Performance Indicators (KPIs) Systemprobleme aufdecken. Beispielsweise können ausgereizte Betriebssystem-Handles (OS) ein System verlangsamen und erfordern oft einen Neustart, um die Funktionalität wiederherzustellen.

Metriken werden häufig aggregiert, um eine zusammenfassende Ansicht bereitzustellen, die Dashboards und andere Visualisierungen (z. B. Zeitreihendiagramme) verwendet, um Entwicklern zu helfen, den Gesamtzustand des Systems schnell zu bewerten, Datentrends zu analysieren und auf Netzwerkprobleme zu reagieren. Sie dienen auch als Grundlage für Entscheidungen über die Skalierung und Ressourcenzuweisung, sodass Metriken für eine effektive Kapazitätsplanung und Lastverwaltung unerlässlich sind.

Es ist kritisch, dass die Teams sorgfältig auswählen, welche Metriken sie verfolgen und kontinuierlich analysieren, da einige Metriken ihnen helfen können, potenzielle Probleme vorherzusehen, bevor sie auftreten.

Teams können Metriken-Schwellenwerte festlegen, deren Überschreitung Alarme auslöst, um IT-Mitarbeiter über aktuelle oder drohende Probleme zu informieren. Mithilfe von Metriken können Observability-Tools auch Probleme – wie z. B. OS-Handle-Leck – erkennen, die sich im Laufe der Zeit anhäufen, und zwar lange bevor sie die Erfahrung beeinträchtigen.

Allerdings bieten Metriken oft nur einen begrenzten Kontext, sodass sie in der Regel mit Protokollen und Traces korreliert werden müssen, um Entwicklern ein umfassendes Verständnis von Systemereignissen zu vermitteln. Metriken mit hoher Auflösung generieren auch riesige Datenmengen, die sich nur schwer effizient speichern und verwalten lassen. Daher erfordert die Beobachtbarkeit oft hochwertige Langzeitspeicherlösungen, die Metrikdaten verarbeiten können und ihre Verfügbarkeit für Analysen sicherstellen.

Protokolle sind unveränderliche, umfassende Aufzeichnungen diskreter Ereignisse, die in einem System auftreten. Sie helfen den Teams, das „Warum“ von Systemproblemen zu verstehen.

Protokolldateien speichern detaillierte Informationen zum Systemverhalten und zu Anwendungsprozessen, z. B.:

• Zeitstempel für Ereignisse
• Transaktions-IDs
• IP-Adressen und Benutzer-IDs
• Details zu Ereignis und Ablauf
• Fehlermeldungen
• Verbindungsversuche
• Konfigurationsänderungen

Ereignisprotokolle können binär, unstrukturiert (wie im Klartext) oder strukturiert (wie im JSON-Format) sein. Alle Protokolldateien sind im richtigen Kontext nützlich, aber strukturierte Protokollierung strukturiert Text und Metadaten so, wie sie generiert werden, sodass sie einfacher zu parsen und zu analysieren sind.

Die Protokollierungsfunktionen innerhalb von Observability aggregieren Protokolldateien von Betriebssystemen, Netzwerkgeräten, internen und Drittanbieteranwendungen sowie Geräten des Internet der Dinge (IoT), um Entwicklungsteams dabei zu helfen, Fehler zu diagnostizieren und Systemausfälle zu verstehen. Wenn ein Fehler, eine Sicherheitsverletzung oder ein Compliance-Problem auftritt, liefern Protokolle die Details, die Sie benötigen, um die Ursache zu finden und zu verstehen, was falsch gelaufen ist.

Protokolle bieten wertvolle Erkenntnisse in Systemereignisse und -probleme, zeichnen aber allein ein unvollständiges Bild. Wie bei Metriken müssen Observability-Tools Protokolldaten analysieren und mit Metriken und Traces korrelieren, um ihren Wert zu maximieren. Und genau wie Metriken erhöhen Protokolle das Datenvolumen erheblich, sodass Unternehmen häufig in ausgeklügelte Log-Management-Tools investieren müssen, um die Datenlast zu bewältigen.

Darüber hinaus kann eine umfassende Protokollierung wichtige Informationen unter weniger relevanten Daten verbergen und so „Rauschen“ erzeugen, das die Identifizierung von Problemen für IT-Mitarbeiter erschwert. Aus diesem Grund setzen moderne Observability-Lösungen auf KI- und maschinelles Lernen (ML)-gesteuerte Automatisierungsworkflows, um die Alarmierungspraktiken zu verfeinern und zwischen kritischen Alarmen und Störfaktoren zu unterscheiden.

Traces, die einige Funktionen von Metriken und Protokollen kombinieren, ordnen Daten über Netzwerkkomponenten hinweg zu, um den Workflow einer Anfrage anzuzeigen. Sie stellen den gesamten Weg einer Anfrage durch das Netzwerk dar und erfassen den Weg und die Lebensdauer jeder Komponente, die an der Bearbeitung der Anfrage beteiligt ist. Kurz gesagt, Tracing hilft Site Reliability Engineers (SREs) und Software-Engineering-Teams, das „Wo“ und „Wie“ von Systemereignissen und -problemen zu verstehen.

Zu den Traceerstellungsdaten können gehören:

• Die Dauer von Netzwerkereignissen und -operationen
• Der Fluss von Datenpaketen durch die Architektur
• Die Reihenfolge, in der Anforderungen die Netzwerkdienste durchlaufen
• Die Ursache von Systemfehlern

Tracing, oder viel mehr verteiltes Tracing, ist in Microservice-Architekturen nützlich, wo Anfragen mehrere, geografisch verteilte Dienste durchlaufen können, bevor sie ihr Ziel erreichen. Es bietet Erkenntnisse in die Abhängigkeiten und Interaktionen zwischen verschiedenen Komponenten und Diensten und kann IT-Teams helfen, zu verstehen, wie lange Benutzer benötigen, um bestimmte Aktionen auszuführen.

Die Observability-Funktionen in Observability-Tools sind für Latenzanalysen unerlässlich, die Ingenieuren helfen, problematische Komponenten und unterleistungende Dienste zu identifizieren, die zu Leistungsbottlenecks für Benutzer führen können.

Sie erleichtern Debugging-Prozesse, indem sie Anfrage-Antwort-Abläufe und kausale Beziehungen zwischen Netzwerkelementen veranschaulichen. Und während der Ursachenanalyse helfen Traces den Teams, die Ursache von Netzwerkproblemen in komplexen Workflows zu lokalisieren, um Probleme schneller und genauer zu lösen.

Im Gegensatz zu Metriken und Protokollen können Traces Kontextinformationen liefern, um Erkenntnisse anzureichern. Durch die Traceerstellung allein können jedoch keine Datentrends oder -muster aufgedeckt werden. Die Einrichtung verteilter Traces erfordert auch eine dienstübergreifende Messwerterfassung, was den Prozess besonders komplex und zeitaufwändig machen kann. Und wenn es nicht ordnungsgemäß verwaltet wird, kann die Traceerstellung, und die dafür erforderliche Rechenleistung, zu mehr Latenz in der Umgebung führen.

Die Kombination aller drei Säulen ermöglicht es Entwicklungs- und Betriebsteams, eine ganzheitliche Sicht und ein granulares Verständnis des komplexen Systemverhaltens zu erhalten. Während Metriken verwendet werden, um Teams auf Probleme aufmerksam zu machen, zeigen Traces den Weg zu deren Ausführung und Protokolle liefern den Kontext, der zur Lösung der Probleme erforderlich ist.

Gemeinsam tragen sie dazu bei, die Identifizierung und Lösung von Problemen zu beschleunigen, bieten Teams ergänzende Tools zur Problemlösung, optimieren die Leistung und ermöglichen Full Stack Observability.

Metriken, Protokolle und Traces sind weithin als die wichtigsten Säulen der Observability bekannt, aber das schließt die Existenz weiterer grundlegender Komponenten nicht aus. Einige würden einwenden, dass Kontext, Korrelation und Alerting ebenfalls Säulen der Observability sind.

Schließlich bereichert der Kontext Metriken, Protokolle und Traces, indem er zusätzliche Informationen über die Netzwerkumgebung bereitstellt (z. B.Topologie, Geräterollen und Anwendungsabhängigkeiten). Ohne Kontext hätten die Observability-Daten keine umsetzbare Bedeutung.

Die Korrelation verbindet Metriken, Logs, Traces und kontextbezogene Informationen miteinander, um einen zusammenhängenden Überblick über die Ereignisse in den verschiedenen Schichten des Netzwerk-Stacks zu erhalten. Und ohne Alerts wären Observability-Tools nicht in der Lage, Prompt Benachrichtigungen zu senden, wenn Probleme auftreten.

Die Profilerstellung entwickelt sich jedoch zu einem weiteren Hauptmerkmal der Observability.

Profiling, auch kontinuierliches Profiling genannt, ist der Prozess der Ausführung einer Anwendung und der kontinuierlichen Erfassung detaillierter Daten über den Status der Codeausführung zu bestimmten Momenten. Profile können beispielsweise aufzeigen, ob sich Java-Threads in einem RUNING- oder WAIT-Zustand befinden. Oder wenn bei einer App Probleme mit Speicherlecks auftreten, können Profile dabei helfen, zu klären, welcher Teil des Codes übermäßig Ressourcen verbraucht.

Daher dienen die Profile als Röntgenaufnahmen der internen Funktionsweise einzelner Komponenten.

Die Profilerstellung ist nützlich, um Probleme auf niedriger Ebene zu identifizieren, die z. B. einzelne Funktionen oder Codeblöcke betreffen. Es hilft IT-Teams, belegte Codepfade zu identifizieren, ungenutzte Pfade zu lokalisieren und zu deaktivieren sowie entscheidende Pfade für zukünftige Ereignisse und Interaktionen zu priorisieren.

Obwohl Profile keine der drei Säulen sind, haben sich die Profilierungsfunktionen erheblich entwickelt. Projekte wie der erweiterte Berkeley Packet Filter (eBPF) für den Linux-Kernel haben die Profiler-Entwicklung rationalisiert und die Profilierungsprozesse für Entwicklungsteams vereinfacht.

Entwicklungsteams können Tracing-, Sampling- und Instrumentierungsprofile nutzen, um tiefere und differenziertere Einblicke in den Anwendungscode zu erhalten. Und in Verbindung mit anderen Säulen der Observability kann die Profilerstellung Echtzeit-Einblicke in die Leistung liefern, den Lebenszyklus der Softwareentwicklung beschleunigen und Unternehmen bei der Optimierung ihrer DevOps-Strategie unterstützen.