Was ist OpenTelemetry? Eine umfassende Einführung

Was ist OpenTelemetry? Kurz gesagt: OpenTelemetry ist ein Open-Source Observability-Framework. Sie bietet herstellerunabhängige oder herstellerneutrale APIs, Software-Entwicklungskits (SDKs) und andere Tools zur Erfassung von Telemetriedaten aus cloudnativen Anwendungen und ihrer unterstützenden Infrastruktur. So gelingt es, deren Leistung und Zustand zu verstehen.

In den modernen komplexen, verteilten Umgebungen ist Performance-Management extrem schwierig. Telemetriedaten sind sehr wichtig, da sie DevOps- und IT-Teams helfen, das Verhalten und die Performance dieser Systeme zu verstehen. Damit sie sich ein vollständiges Bild vom Verhalten ihrer Services und Anwendungen machen können, müssen diese Teams alle ihre Frameworks und Bibliotheken für viele verschiedene Programmiersprachen instrumentieren.

Es gibt allerdings keinen kommerziellen Anbieter, der ein Einzelinstrument oder -Tool für die Datenerfassung aus sämtlichen Anwendungen eines Unternehmens anbietet. Dies führt zu Datensilos und einem Mangel an Einheitlichkeit, die das Troubleshooting und die Lösung von Leistungsproblemen erschweren.

OpenTelemetry ist wichtig, da es die Erfassung und Übertragung von Telemetriedaten an Backend-Plattformen standardisiert. Es schließt Lücken in der Sichtbarkeit, indem es Service-übergreifend ein einheitliches Instrumentierungsformat bereitstellt. Entwickler müssen nicht bei jedem Wechsel einer Backend-Plattform den Code neu instrumentieren oder andere proprietäre Agents installieren. Außerdem wird OpenTelemetry auch beim Aufkommen neuer Technologien weiterhin funktionieren – ganz im Gegensatz zu kommerziellen Lösungen, deren Anbieter neue Integrationslösungen entwickeln müssen, um die Interoperabilität ihrer Produkte sicherzustellen.

In den folgenden Abschnitten sehen wir uns OpenTelemetry und seine Funktionsweise näher an und untersuchen, wie es Unternehmen hilft, bei ihren verteilten Systemen für die nötige Observability zum Erreichen ihrer Geschäftsziele zu sorgen.

Eine Einführung in Telemetriedaten

Telemetriedaten sind die Ausgabe, die im Rahmen von Observability aus Systemquellen erfasst wird. Werden diese Daten gemeinsam analysiert, bieten sie eine Sicht auf die Beziehungen und Abhängigkeiten innerhalb eines verteilten Systems. Es werden im Wesentlichen drei Datenkategorien verwendet, die oft als „die drei Säulen der Observability“ bezeichnet werden: Logs, Metriken und Traces.

• Logs: Ein Log oder Protokoll ist eine Textaufzeichnung eines Ereignisses, das zu einem bestimmten Zeitpunkt stattfand. Bei jeder Ausführung eines Codeblocks entsteht ein Log-Eintrag, der den Zeitpunkt des Ereignisses aufzeichnet und Kontext dazu liefert. Log-Daten gibt es in drei Formaten: Klartext, strukturiert und unstrukturiert. Klartext beziehungsweise einfacher Text ist am weitesten verbreitet. Doch strukturierte Logs, die zusätzliche Metadaten enthalten und leichter abzufragen sind, erfreuen sich immer größerer Beliebtheit. Unstrukturierte Logs sind hingegen schwieriger zu analysieren. Logs sind in der Regel die Quelle der Wahrheit für das, was die Anwendung tut. Dort schaut man hin, wenn etwas in einem System schiefgeht, und Entwickler verlassen sich darauf, um ihren Code zu debuggen und dessen Ausführung zu überprüfen. Ein Systemausfall hat in der Regel mehrere Gründe (manchmal als Hauptursachen bezeichnet). Die Protokollierung liefert uns detaillierte Informationen bei der Ausführung von bestimmten Codeblöcken.
• Metriken: Bei einer Metrik handelt es sich um einen numerischen Wert, der über ein Zeitintervall gemessen wird. Sie enthält spezifische Attribute wie einen Zeitstempel, den Namen eines Ereignisses und dessen Bedeutung. Im Gegensatz zu Logs sind Metriken standardmäßig strukturiert, was ihre Abfrage erleichtert. Sie sind auch für die Speicherung optimiert, sodass ihr mehr Metriken über längere Zeiträume aufbewahrt könnt. Das verschafft einen besseren Überblick über die historischen Trends eines Systems. Metriken eignen sich am besten für große Datensätze oder regelmäßig erfasste Daten, falls ihr eine Antwort auf eine spezielle Frage sucht. Wir neigen dazu, Metriken über längere Zeiträume zu betrachten, was bei der Analyse von Problemen und die Antwort auf sie eine entscheidende Rolle spielt. Metriken lösen Warnmeldungen aus, entweder in aggregierter Form oder als einzelner Punkt. Oft fungieren sie als erster Indikator für Probleme in unseren Systemen.
• Traces: Ein Trace (eine Rückverfolgung) stellt den gesamten Weg einer Anfrage durch ein verteiltes System dar. Der Weg einer einzelnen Anfrage durch ein System besteht aus vielen Operationen. Jede Operation wird mit wichtigen Daten („Span“ genannt) codiert. Das beinhaltet einen Trace-Identifikator, einen Span-Identifikator, den Namen der Operation, einen Start- und Ende-Zeitstempel, Logs, Ereignisse und andere indexierte Informationen. Durch die Betrachtung eines Traces (auch „Distributed Tracing“ genannt) lässt sich der vollständige Ausführungspfad verfolgen. So stellt ihr fest, welcher Teil des Codes Schwierigkeiten (Fehler, Latenz- oder Ressourcenprobleme) bereitet. Traces können auch Metriken generieren, insbesondere in einer Form, die wir als RED (Rate, Errors & Duration) kennen. Entscheidend ist, dass Traces auch Kontext liefern, um zu bestimmen, welche Instanzen der anderen beiden Säulen für die Fehlersuche bei einem bestimmten Problem am relevantesten sind.

Einzeln erfüllen Logs, Metriken und Traces unterschiedliche Zwecke, aber zusammen liefern sie die umfassenden, detaillierten Einblicke, die ihr zum Verständnis und zur Fehlersuche in verteilten Systemen benötigt. Kommen noch Ereignisse hinzu, heißt der vierteilige Ansatz MELT: Metrics, Events, Logs & Traces.

Wie OpenTelemetry zum Einsatz kommt

OpenTelemetry wird dazu verwendet, Telemetriedaten aus verteilten Systemen zu erfassen, die dann für Troubleshooting, Debugging und Management von Anwendungen und ihrer Host-Umgebung eingesetzt werden. Es bietet IT- und Entwicklerteams eine einfache Möglichkeit, ihre Codebasis für die Datenerfassung zu instrumentieren und mit zunehmender Unternehmensgröße Anpassungen vorzunehmen.

OpenTelemetry erfasst verschiedene Kategorien von Telemetriedaten, einschließlich Logs, Metriken und Traces, und exportiert diese zur Verarbeitung in Backend-Plattformen. Die Analyse dieser Telemetriedaten ermöglicht Teams, mehrschichtige Ökosysteme kohärenter zu machen. Dies macht es deutlich einfacher, das Verhalten der Systeme zu beobachten und Performance-Probleme zu beheben.

Das OpenTelemetry-Framework umfasst verschiedene Komponenten:

• Sprachenspezifische OpenTelemetry-APIs – Java, Python, JavaScript und mehr – für die Instrumentierung von Code für die Datenerfassung
• Exporter ermöglichen die Übertragung von Telemetriedaten an die Backend-Observability-Plattform eurer Wahl.
• Sprachspezifische OpenTelemetry-SDKs bauen eine Brücke zwischen den APIs und den Exportern.
• Der OpenTelemetry Collector bietet eine herstellerunabhängige Implementierung für den Empfang, die Verarbeitung und den Export von Telemetriedaten.

OpenTelemetry ist wichtig für DevOps, da die bereitgestellten Daten Benachrichtigungen, Troubleshooting und das Debugging von Anwendungen vereinfachen. Telemetriedaten wurden zwar schon immer verwendet, um das Systemverhalten zu verstehen, doch die allgemeine Netzwerkkomplexität macht das Erfassen und Analysieren von Tracing-Daten schwieriger. So kann das Nachverfolgen der Ursache eines einzigen Incidents mit herkömmlichen Methoden in diesen labyrinthartigen Systemen Stunden oder gar Tage dauern.

OpenTelemetry verbessert die Observability in diesen Systemen, indem sie Traces, Logs und Metriken aus verschiedenen Anwendungen und Diensten in einer korrelierten Weise zusammenführt. Darüber hinaus beseitigt das Open-Source-Projekt Hindernisse bei der Instrumentierung, sodass Organisationen sich zum Beispiel auf eine wichtige Funktion wie Application Performance Monitoring (APM) konzentrieren können. Unter dem Strich kommt eine höhere Effizienz bei der Identifizierung und Behebung von Vorfällen heraus, eine höhere Zuverlässigkeit der Dienste und geringere Ausfallzeiten.

Die geschäftlichen Vorteile von OpenTelemetry

OpenTelemetry bietet verschiedene Vorteile. Die drei wichtigsten sind:

Konsistenz: Die Praxis, Telemetriedaten aus Anwendungen zu sammeln, existierte schon vor OpenTelemetry, war aber wesentlich schwieriger. Es war nicht einfach, die richtige Zusammenstellung von Instrumenten zu finden. Außerdem war man vertraglich gebunden, sobald man sich für eine bestimmte Lösung oder einen bestimmten Anbieter entschieden hatte. Diese Lösung war über die Anwendungen hinweg wahrscheinlich nicht konsistent. Das machte es nahezu unmöglich, ein ganzheitliches Verständnis der Leistung einer Anwendung zu erhalten.

OpenTelemetry bietet dagegen einen konsistenten Weg für die Erfassung von Telemetriedaten und ihre Übertragung an das Backend, bei dem die Instrumentierung nicht geändert werden muss und im Prinzip ein Standard für das Hinzufügen von Observability zu Cloud-nativen Apps geboten wird. Entwickler und IT können jetzt mehr Zeit auf die Erstellung neuer App-Funktionen aufwenden, da sie nicht mehr mit ihrer Instrumentierung kämpfen müssen.

Einfachere Wahl: Vor OpenTelemetry mussten Organisationen zwischen OpenTracing und OpenCensus wählen, die jeweils einen anderen Observability-Ansatz verfolgten. Da OpenTelemetry den Code dieser beiden Frameworks zusammenführt, erhaltet ihr das Beste aus beiden Welten. Und es besteht kein Risiko beim Wechsel zu OpenTelemetry, wenn ihr zuvor eines der beiden Systeme verwendet habt. OpenTelemetry ist mit beiden abwärtskompatibel.

Optimierte Observability: OpenTelemetry ermöglicht es Entwicklern, Nutzungs- und Leistungsdaten von Anwendungen von jedem Gerät oder Webbrowser aus einzusehen. Diese bequeme Schnittstelle erleichtert die Verfolgung und Analyse von Observability-Daten in Echtzeit.

Der größte Vorteil besteht natürlich darin, die Observability zu realisieren, die zum Erreichen der Unternehmensziele notwendig ist. OpenTelemetry konsolidiert die Telemetriedaten, mit denen Sie feststellen können, ob Systeme ordnungsgemäß funktionieren und wo eventuell Probleme die Leistung beeinträchtigen, sowie Kernursachen beheben können – und zwar möglichst bevor sie eine Service-Unterbrechung verursachen. All dies führt zu mehr Stabilität und Zuverlässigkeit der operativen Geschäftsprozesse.

Nutzung von OpenTelemetry mit KI

OpenTelemetry kann gesammelte Daten in eine KI-Engine einspeisen, um automatisch verwertbare Erkenntnisse zu generieren. Die KI-Engine kann beispielsweise ganz ohne menschliches Eingreifen von OpenTelemetry erfasste Daten zusammen mit anderen nützlichen, gefragten Daten kontinuierlich analysieren und im gesamten Stack nach Anomalien suchen. Die KI kann Milliarden von Abhängigkeiten innerhalb eines verteilten Systems in Sekundenbruchteilen erkennen und verarbeiten und dadurch verdeckte Aktivitäten aufspüren. Außerdem kann sie die Ursache von Problemen automatisch identifizieren und, wenn möglich bzw. gewünscht, beheben, bevor sich Auswirkungen für den Endbenutzer ergeben. Bei diesem kontinuierlichen Prozess lernt die KI, was der „Normalzustand“ des Systems ist, und kann ihre Antworten entsprechend anpassen, um ihre Performance mit der Zeit zu verbessern – auch im Hinblick auf die Fähigkeit, Probleme vor ihrem Auftreten zu prognostizieren.

Die KI-Integration steigert im Grunde den Nutzen von OpenTelemetry, indem sie den nötigen manuellen Aufwand reduziert, um Observability für die Analyse von Zuständen einzusetzen, und es zudem erleichtert, verwertbare Erkenntnisse zu gewinnen.

Was ist OpenTracing?

Bei OpenTracing handelt es sich um herstellerneutrale API-Spezifikationen, Frameworks und Bibliotheken, die keinem bestimmten Unternehmen gehören. Sie helfen Entwicklern dabei, Tracing einfach in ihre Codebasis zu implementieren. OpenTracing vereinfacht den verteilten Tracing-Prozess, indem es einen Standardmechanismus bereitstellt, den Entwickler zur Instrumentierung ihres eigenen Codes nutzen können. Dabei sind sie an keinen bestimmten Tracing-Anbieter gebunden.

Dezentrales Tracing (manchmal auch dezentrales Anforderungs-Tracing genannt) ist eine Methode für das Monitoring von Anwendungen, die auf einer Microservices-Architektur aufsetzen. Programmierer verwenden Tracing zusammen mit anderen Logging-Methoden, um Informationen über das Verhalten einer Anwendung zu sammeln. Entwickler nutzen diese Informationen für das Debugging, und Systemadministratoren, technischer Support und andere verwenden sie für das Troubleshooting von Apps und Services.

Die Observability-Grundlagen

Bei Observability wird der Zustand eines Systems anhand seiner Ausgaben gemessen. Der Begriff stammt aus der Steuerungstheorie, bei der es um das Beschreiben und Verstehen selbstregelnder Systeme geht. Immer mehr Unternehmen setzen bei ihren verteilten Systemen auf Observability, um ihre Performance zu verstehen und zu verbessern. In diesem Kontext werden für Observability Telemetriedaten genutzt, um detaillierte Einblicke in diese Systeme zu geben und Teams Antworten auf vielfältige Fragen über das Systemverhalten zu liefern.

Aufgrund der großen Zahl ineinander greifender Elemente, die durch lose Kommunikationswege verknüpft sind, ist die Verwaltung verteilter Systeme nicht einfach. Außerdem treten dadurch bei diesen Systemen mehr und vielfältigere Fehler auf, und es ist schwierig, Probleme beim aktuellen Zustand eines verteilten Systems zu verstehen, geschweige denn künftige Probleme zu prognostizieren. Im Prinzip produzieren verteilte Systeme mehr „unbekannte Unbekannte“ als einfachere Systeme. Da konventionelles Monitoring auf „bekannten Unbekannten“ basiert, lassen sich Probleme in solch komplexen Umgebungen damit nur schwer identifizieren.

Observability ist besser für diese Unvorhersehbarkeit geeignet. Sie ermöglicht eine bessere Kontrolle dieser komplexen, modernen Systeme und macht es leichter, ihr Verhalten zu verstehen. Teams können unterbrochene Verknüpfungen in einer komplexen Umgebung leichter erkennen und zu ihrem Ursprung zurückverfolgen. Außerdem ermöglicht Observability Entwicklern mit Fragen wie „Warum ist X defekt?“ oder „Was verursacht momentan Latenz?“ einen erklärenden Ansatz bei Systemfehlern zu verfolgen.

Um Observability zu erreichen, müssen Sie Ihr System und seine Apps auf die Erfassung der passenden Telemetriedaten vorbereiten. Sie können dafür eine kommerzielle Observability-Plattform kaufen, eine Open Source-Lösung nutzen oder ein eigenes Tool entwickeln. In jedem Fall beinhaltet Observability vier Komponenten:

• Instrumentierung: Messwerkzeuge sammeln Telemetriedaten von CPUs, Containern, Diensten, Anwendungen und allen anderen Komponenten eures Systems, die Daten erzeugen. Dies sorgt für Transparenz über eure gesamte Infrastruktur hinweg, wenn ihr neue Komponenten und Datentypen hinzufügt. Automatische Instrumentierung spielt eine entscheidende Rolle für eine schnelle Implementierung.
• Datenkorrelation: Die von eurem System gesammelten Telemetriedaten werden verarbeitet und korreliert. Dies schafft Kontext und ermöglicht eine automatisierte oder benutzerdefinierte Datenkuration für die Visualisierungen des Observability-Tools.
• Incident Response: Automatisierte Technologien leiten Informationen über Ausfälle an die richtigen Personen und Teams weiter.
• AIOps: Maschinelles Lernen aggregiert, korreliert und priorisiert Daten über Zwischenfälle automatisch. Dies reduziert unnötige Warnmeldungen und ermöglicht es Teams, Probleme schneller zu erkennen und entsprechend zu reagieren.

Mithilfe von OpenTelemetry könnt ihr Observability erreichen. Organisationen müssen ihre gesamte Infrastruktur verändern, um eine durchgängige (End-to-End) Transparenz zu erreichen. Dies erreicht ihr mit einer einzelnen kommerziellen Lösung kaum, aber OpenTelemetry standardisiert die zur Erfassung der Telemetriedaten erforderliche Instrumentierung und ermöglicht Observability.

Die Geschichte und Zukunft von OpenTelemetry

Das OpenTelemetry-Projekt befindet sich noch in einem frühen Stadium. Es befindet sich derzeit in der Beta-Phase und unterstützt nur Traces und Metriken; die Unterstützung für Logs steckt ¬noch in der Planungsphase. Die Projektteams arbeiten daran, die OpenTelemetry-Kernkomponenten zu stabilisieren, die automatisierte Instrumentierung durch Agenten zu integrieren, die Sprachkompatibilität zu erweitern und die Metrik-Funktionen zu verbessern. Von diesem Punkt aus sollte die allgemeine Verfügbarkeit einer produktionsreifen Version möglich sein. OpenTelemetry ist eines der größten Open-Source-Projekte der CNCF (neben Prometheus und Kubernetes). Das Projekt erhält beträchtliche Unterstützung aus der Technologie-Community. OpenTelemetry wird schließlich das dominierende Observability-Framework in der cloudnativen Telemetrie-Landschaft sein.

OpenTelemetry ist die Kombination aus den zwei sich überschneidenden Open Source-Projekten für dezentrales Tracing OpenTracing und OpenCensus, die in diesem Projekt zusammengeführt wurden.

Das von der Cloud Native Computing Foundation (CNCF) gehostete OpenTracing war der Versuch, eine standardisierte API für Tracing zu etablieren. Es ermöglichte Entwicklern unter anderem, Instrumentierung in häufig verwendete Bibliotheken oder ihren eigenen Code einzubetten, ohne sich an einen bestimmten Anbieter zu binden. Dieses Konzept war zum Zeitpunkt seiner Implementierung einzigartig. Doch obwohl OpenTracing Entwicklern zwar die dringend benötigte Flexibilität bot, war diese API von begrenztem Nutzen und wurde nur inkonsistent implementiert, da der Fokus ausschließlich auf Tracing lag.

Google entwickelte OpenCensus auf der Basis seiner internen Tracing-Plattform. Nach der Freigabe als Open Source-Projekt engagierten sich Microsoft und andere Anbieter und Förderer bei der Weiterentwicklung des Standards. OpenCensus umfasste eine Reihe mehrsprachiger Bibliotheken, die Metriken zum Anwendungsverhalten sammelten und diese Daten dann zur Unterstützung beim Debugging an die vom Entwickler gewählte Analyseplattform im Backend übertrugen. Außerdem konnte OpenCensus Meldungen, Anforderungen und Services von ihrer Quelle bis zum Ziel verfolgen. Da es allerdings keine API für die Einbettung von OpenCensus in Code gab, mussten Entwickler für diese Aufgabe von Communities erstellte automatische Instrumentierungsagenten einsetzen.

OpenTelemetry entstand als sich die beiden Projekte darauf einigten, die Codebasen von OpenTracing und OpenCensus zusammenzulegen und damit die Stärken beider Projekte unter der Kontrolle der CNCF zusammenzuführen. OpenTelemetry (derzeit Beta) bietet „eine Sammlung von APIs, Bibliotheken, Agenten und Datenkollektorservices für die Erfassung dezentraler Anwendungs-Traces und -metriken (und bald auch Logs), die dann mit gängigen Observability-Tools analysiert werden können.

Die verschiedenen Arten verteilter Bereitstellungen

Verteilte Bereitstellungen reichen von kleinen Bereitstellungen für einzelne Abteilungen auf LANs bis hin zu riesigen weltweiten Bereitstellungen. Neben der Größe und der Komplexität insgesamt können Organisationen sich aufgrund der Größe und Kapazität ihres Computernetzwerks, der Datenmenge, um die es geht, der Häufigkeit ihrer Prozesse, ob sie geplant ausgeführt werden sollen oder ad hoc, der Anzahl der Benutzer, die auf das System zugreifen, der Kapazität ihres Rechenzentrums, der erforderlichen Datentreue und ihrer Verfügbarkeitsanforderungen für die geeignete Bereitstellung entscheiden.

Auf der Grundlage dieser Überlegungen werden verteilte Bereitstellungen als Bereitstellungen für Abteilungen, kleine Unternehmen, mittelständische Unternehmen oder große Unternehmen kategorisiert. Auch wenn es keine offiziellen Taxonomien gibt, durch die sich abgrenzen lässt, was ein mittelständisches Unternehmen von einem großen Unternehmen trennt, so stellen diese Kategorien einen Ausgangspunkt für die Planung der benötigten Ressourcen für ein verteiltes Computing-System dar. Verteilte Systeme lassen sich im Laufe der Zeit weiterentwickeln, wenn sie mit zunehmender Erweiterung des Unternehmens den Übergang von der Abteilung hin zu einem kleinen Unternehmen schaffen.

Die Bedeutung von verteilten Systemen

Modernes Computing wäre ohne verteilte Systeme nicht möglich. Sie sind unverzichtbar für die Operationen kabelloser Netzwerke, Cloud-Computing-Dienste und das Internet. Wenn es keine verteilten Systeme gäbe, würden auch diese Technologien nicht existieren.

Aber brauchen wir auch verteilte Systeme für Aufträge auf Unternehmensebene, die nicht die Komplexität eines kompletten Telekommunikationsnetzwerks haben? In den meisten Fällen lautet die Antwort ja. Verteilte Systeme bieten eine Skalierbarkeit und bessere Leistung, an die monolithische Systeme nicht heranreichen, und da sie sich die Funktionen anderer Datenverarbeitungsgeräte und Prozesse zunutze machen, bieten verteilte Systeme Funktionen, die auf einem einzelnen System nicht oder nur schwer entwickelt werden könnten.

Dazu gehört unter anderem die Durchführung eines externen Back-ups von Servern und Anwendungen. Sollte der Hauptstrang die benötigten Segmentbits für eine Wiederherstellung nicht finden, kann er die anderen externen Knoten auffordern, die Segmente zu senden. Letztendlich nutzt aber praktisch alles, was ihr heute mit einem Computer tut, die Leistungsfähigkeit verteilter Systeme, sei es das Senden einer E-Mail, das Spielen eines Spiels oder das Lesen dieses Artikels im Web.

Fazit: Die digitale Vernetzung macht OpenTelemetry unerlässlich

In den letzten zwanzig Jahren hat die Digitalisierung die Arbeitswelt verändert, und mobile Apps und auch Web-Apps sind wichtiger denn je.

Die Datenerfassung ist ein wichtiger Faktor für diese Cloud-nativen Anwendungen, doch viele Unternehmen sind nicht dafür ausgerüstet. Branchenübergreifend geben 57 % der Unternehmen an, dass das Datenvolumen schneller zunimmt als sie ihre Möglichkeiten zur Datenverwertung ausbauen können, und 47 % sind der Ansicht, dass ihr Unternehmen mit diesem rasanten Wachstum der Datenmenge nicht Schritt halten kann. Und während der Großteil zustimmt, dass Daten für den Gesamterfolg und die Innovationskraft unerlässlich sind, geben ganze zwei Drittel an, dass mindestens die Hälfte ihrer Daten Dark Data sind – das entspricht einem Anstieg um 10 Prozent gegenüber dem Vorjahr.

OpenTelemetry ist der Schlüssel zur Kontrolle eurer Telemetrie und zur Förderung der umfassenden Transparenz, die ihr zur Verbesserung eurer Observability-Praktiken benötigt. OpenTelemetry bietet Tools, mit denen ihr Daten aus eurem gesamten Technologie-Stack sammeln könnt, ohne euch in werkzeugspezifischen Überlegungen zu verirren. Letztendlich trägt es dazu bei, die Performance eurer Anwendungen zu fördern und die Geschäftsergebnisse erheblich zu verbessern.