Mit OpenTelemetry Traces in Metriken umwandeln

Distributed Tracing beleuchtet die komplexe Funktionsweise einer Anwendungsinfrastruktur und bietet einen detaillierten Einblick in Anfragen und Transaktionen. Durch die Konsolidierung von Event-Aufzeichnungen über die gesamte Breite eines verteilten Systems werden Traces für die Diagnose von Fehlerursachen und die Identifizierung von Performance-Anomalien unverzichtbar. Doch obwohl ihr Detailreichtum anfangs von unschätzbarem Wert ist, stellen sie aufgrund steigender Kosten und sinkender Erträge für das langfristige Monitoring Probleme hinsichtlich der Nachhaltigkeit dar.

Willkommen in der Welt der Metriken, wo die Aggregation von Daten im Zeitverlauf einen umfassenden Überblick über System-Health und -Performance liefert und gleichzeitig für eine längere Beobachtung deutlich kostengünstiger ist. Diese Neuausrichtung verspricht nicht nur mehr Effizienz, sondern gewährleistet auch eine nachhaltige, umfassendere Perspektive auf die Systemdynamik.

Stellen Sie sich vor, Sie könnten Trace-Daten in dauerhafte, aufschlussreiche Metriken umwandeln und so die unmittelbaren, detaillierten Einblicke aus dem Tracing mit der langfristigen, aggregierten Perspektive der Metriken verbindet.

Dieser Blogpost führt Sie durch die Konvertierung von Traces in Metriken mithilfe von OpenTelemetry und zeigt einen unkomplizierten Weg auf, wie Sie aus Ihren Trace-Daten langlebige, wertvolle Metriken gewinnen können.

Mit Metriken lassen sich Probleme besser lösen

Die Kosten für Ihre Observability-Lösung hängen vom Anbieter und von der Größe Ihrer Infrastruktur ab, aber es ist kein Geheimnis, dass Observability teuer werden kann. Für eine umfassende Observability-Lösung benötigen Sie Distributed Tracing , um zu verstehen, welchen Verlauf einzelne Anfragen und Transaktionen durch Ihre Infrastruktur nehmen; Sie brauchen Metriken, um Health und Performance Ihrer Systeme im Zeitverlauf zu erfassen, und Logs, um detaillierte, kontextbezogene Informationen zu bestimmten Events und Fehlern in Ihren Systemen zu erhalten. 

Da Traces sehr detailliert sind, erfordern sie beträchtlichen Speicherplatz und Rechenressourcen für die Verarbeitung und Analyse. Durch die Aggregation dieser Daten in Metriken können Unternehmen das gespeicherte und verarbeitete Datenvolumen deutlich reduzieren und so die Infrastrukturkosten senken. 

Beispielsweise wurden durch die Erfassung von 3.000 Traces mit 7 Spans 0,0176 GB erfasster Daten generiert. Im Vergleich dazu führten die vom Collector gesendeten transformierten Metriken für die gleiche Menge an Traces nur zu einer Datenmenge von 0,0095 GB. Das bedeutet einen Rückgang der Datenmenge für die transformierten Metriken um fast 50 %. Mit diesem Repository können Sie ein Benchmarking Ihrer Datenerfassung durchführen.

Kapazitätsplanung und Ressourcenzuweisung

Trace-Daten können für die Kapazitätsplanung verwendet werden, da sie bei der Ermittlung von Bottlenecks helfen und Abhängigkeiten verdeutlichen. Anhand der Daten erkennen Sie, wo die Ressourcen möglicherweise nicht ausreichen, und können vorhersagen, wie sich Änderungen in einem Bereich auf andere Bereiche auswirken könnten. Für eine effektive Kapazitätsplanung liefern Metriken wertvolle Einblicke in Nutzungstrends und Ressourcenverbrauch und erleichtern so die Entscheidungsfindung hinsichtlich Skalierung und Ressourcenzuteilung. Dies trägt dazu bei, die Kosten zu optimieren und sicherzustellen, dass das System zukünftige Anforderungen bewältigen kann.

Alerting und Anomalieerkennung

Metriken sind für die Einrichtung effizienter Alert-Systeme unerlässlich. Durch die Festlegung von Schwellenwerten auf der Grundlage von Metrikdaten können Teams umgehend über Anomalien oder Abweichungen vom normalen Verhalten informiert werden, was schnelle Korrekturmaßnahmen ermöglicht. Es ist einfach, einen Schwellenwert für die CPU-Auslastung oder die Antwortzeit festzulegen. Da Traces sehr detailliert sind und für individuelle Anfragen gelten, eignen sie sich allerdings nicht so gut zur Schaffung effektiver Schwellenwerte für das Alerting.

Identifizieren von Performance-Bottlenecks

Mit Traces erhalten Sie Einblicke in einzelne Transaktionen oder Anfragen, was ohne umfassende Aggregation und Analyse nicht zu einem Verständnis der Gesamtnutzungsmuster führt. Metriken bieten sowohl granulare (z. B. Metriken je Service oder Container) als auch aggregierte Ansichten (z. B. CPU-Gesamtauslastung in einem Cluster). Diese Flexibilität ermöglicht es, einerseits gezielt in bestimmte Problembereiche vorzudringen und andererseits einen umfassenden Überblick über die System-Health zu behalten.

Mit dem OpenTelemetry Collector Traces in Metriken umwandeln

OpenTelemetry ist ein solides Open-Source-Framework für Observability, das mit einem Toolkit zum Generieren, Sammeln und Verwalten von Traces, Metriken und Logs ausgestattet ist. Eine Kernkomponente des Frameworks ist der OpenTelemetry Collector, ein vielseitiges Tool, das die Orchestrierung der Datenpipelines für diese Telemetrietypen vereinfacht. Nachdem Sie Metriken, Traces und Logs über Otel-Agents wie den Collector erfasst haben, können Sie die Daten über eine ETL-Pipeline (Pipeline zum Extrahieren, Transformieren und Laden) umwandeln. Jede Pipeline besteht aus vier Schlüsselkomponenten: Empfänger, Prozessoren, Konnektoren und Exporter. Heute sprechen wir über den Span-Metriken-Prozessor sowie den Span-Metriken-Konnektor und welche Vorteile der Span-Metriken-Konnektor gegenüber dem Prozessor bietet.

Span-Metriken-Prozessor

Der Span-Metriken-Prozessor wurde ursprünglich entwickelt, um Metriken aus Span-Daten in OpenTelemetry-Traces zu aggregieren und so eine Verbindung von Telemetriedaten mit der Metrikenanalyse zu schaffen. Allerdings beeinträchtigte sein Design, bei dem das OpenTelemetry-Datenmodell mit den Namenskonventionen für Prometheus-Metriken und -Attribute kombiniert wurde, unbeabsichtigt die Fähigkeit, Exporterlogik-neutral zu bleiben. Dieser Ansatz widersprach der Kernaufgabe von OpenTelemetry, Telemetriedaten über verschiedene Tools und Plattformen hinweg zu standardisieren. Die OpenTelemetry-Community hat diese Herausforderungen erkannt und seitdem den Span-Metriken-Prozessor zugunsten des Span-Metriken-Konnektors abgeschafft.

Was ist also ein Konnektor?

Ein Konnektor dient zum Senden von Telemetriedaten zwischen verschiedenen Collector-Pipelines, indem er diese verbindet. Ein Konnektor fungiert als Exporter für eine Pipeline und als Empfänger für eine andere. Ein weiterer Vorteil der Konnektor-Komponente besteht darin, dass sie die Collector-Konfiguration durch die Verbindung zweier Telemetriepipelines vereinfacht. Wenn Sie Prozessoren verwenden und mit zwei Pipelines arbeiten, müssen Sie Empfänger und Exporter manuell konfigurieren.

Span-Metriken-Konnektor

Der Span-Metriken-Konnektor ist eine Portierung des Span-Metriken-Prozessors und wurde entwickelt, um einige der im Prozessor auftretenden Probleme zu beheben. Zu den Verbesserungen gehörten Änderungen an den Namenskonventionen, um sie an das Otel-Datenmodell anzupassen. Unterstützung für exponentielle Otel-Histogramme und die Generierung von Metrik-Ressourcenbereichen, die der Anzahl der Spans-Ressourcenbereiche entsprechen. Das bedeutet, dass jetzt mehr Metriken generiert werden.  

Konfigurieren des Collectors

Die grundlegende Einrichtung des Span-Metriken-Konnektors ist ziemlich einfach. Unten finden Sie die Konfiguration, die ich in einer Demo erstellt habe, um den Span-Metriken-Konnektor zu erläutern. Nachdem Sie den Span-Metriken-Konnektor selbst konfiguriert haben, müssen Sie ihn als Exporter für die Traces-Pipeline und als Empfänger für die Metriken-Pipeline einbinden. Bei dieser Konfiguration werden sowohl die ursprünglichen Tracing-Daten als auch die daraus transformierten Metriken an ein Observability-Backend gesendet, in diesem Fall New Relic. 

Sampling

Wenn Sie Distributed Tracing verwenden, besteht eine hohe Wahrscheinlichkeit, dass Sie irgendeine Form der Stichprobenerhebung – des Sampling – verwenden. Unabhängig davon, ob Sie Head-Sampling, Tail-Sampling oder beides verwenden, ist es wichtig zu verstehen, wie Sie diesen Prozess maximal ausschöpfen können.

Implementierung des Span-Metriken-Konnektors mit headbasiertem Sampling

Der Standard-Sampler von OpenTelemetry setzt sich aus zwei Samplern zusammen: dem ParentBased-Sampler, der über einen erforderlichen Parameter verfügt, der wiederum angibt, welcher Sampler für Root-Spans verwendet werden soll; und in diesem Fall der Standardeinstellung, nämlich dem AlwaysOn-Sampler. Wie der Name schon sagt, erfasst der AlwaysOn-Sampler beim Sampling immer einen Span mit einem Parent Span. Mit der Standardeinstellung erhalten Sie Metriken von allen an den Collector gesendeten Traces, wenn Sie den Span-Metriken-Konnektor verwenden. Anpassungen an der Standard-Sampler-Konfiguration wirken sich auf die Genauigkeit der aus den Trace-Sampling-Daten transformierten Metriken aus. Wenn Sie Metriken aus allen Ihren Traces erhalten und dennoch die Trace-Daten beproben möchten, können Sie den Probabilistic Sampling Processor implementieren. Dieser Prozessor erfasst standardmäßig prozentuale Stichproben von Tracing-Daten anhand von TraceId-Hashing.

Implementierung des Span-Metriken-Konnektors mit tailbasiertem Sampling

Tail-Sampling bietet Ihnen die Möglichkeit, Ihre Traces anhand spezifischer Kriterien zu beproben, die aus verschiedenen Teilen eines Trace abgeleitet wurden. Mit dieser Technik können Sie alle Ihre Traces in Metriken umwandeln und dann nur interessante Traces samplen. Dies ermöglicht die größtmögliche Kontrolle über die Kosten, aber mit der Kontrolle gehen Schwierigkeiten bei Implementierung und Ausführung von Tail-Sampling einher. In der bereitgestellten Demo verwenden wir einen anderen Konnektor. Der Forward Connector wird verwendet, um Daten von einer Pipeline zu einer anderen weiterzuleiten. Dies ermöglicht es uns, Metriken von allen Traces abzurufen und dann an eine zweite Tracing-Pipeline weiterzuleiten, wo vor dem Export in ein Observability-Backend unsere Sampling-Richtlinien angewendet werden.

Fazit

Die Umwandlung von Distributed Traces in Metriken stellt eine hilfreiche Methode zur Verbesserung von Observability- und Monitoring-Strategien dar. Diese Vorgehensweise bietet nicht nur eine effizientere Möglichkeit zur Handhabung von Telemetriedaten, sondern stellt auch sicher, dass Unternehmen eine hohe System-Performance und -zuverlässigkeit aufrechterhalten können. Dieser Ansatz kann zu erheblichen Kosteneinsparungen und einem besseren Verständnis der System-Performance führen und letztendlich die Servicequalität und Kundenzufriedenheit verbessern.

Wenn es um Ihre Observability-Strategie geht, spielen sowohl Distributed Traces als auch Metriken eine wichtige Rolle. Indem Sie sich deren einzigartige Stärken und Schwächen zunutze machen, können Sie Ihre Telemetriedaten optimal ausschöpfen.