Wie OpenTelemetry die Art und Weise verändert, wie wir Apps verfolgen und entwickeln

Beim Ausführen Cloud-nativer Apps ist die Beobachtbarkeit von entscheidender Bedeutung, da die App-Funktionalität aus der Interaktion zwischen einer großen Anzahl an Microservices entsteht, die an mehreren Standorten ausgeführt werden. Die lose gekoppelte Natur von Microservices-Apps bedeutet potenziell, dass jeder Microservice auf seine eigene Weise über seine Aktivitäten berichtet. Ohne ein Tool, das diese Telemetriedaten zusammenstellt und korreliert, ist es äußerst schwierig – wenn nicht unmöglich –, die Verarbeitung einer Anfrage von Anfang bis Ende zu verfolgen, was für die Fehlerbehebung von entscheidender Bedeutung ist.

Auf der Suche nach einem multifunktionalen Beobachtungstool entschied sich das Team hinter dem NGINX Modern Apps Reference Architecture (MARA)-Projekt für OpenTelemetry . Da sich unser OSS-Team für dieses neue Projekt entschieden hat, möchten wir tiefer in die Materie eintauchen. Auf der GlueCon 2022 traf ich mich mit Granville Schmidt, Architekt im Büro des CTO bei F5, um zu besprechen, warum wir vom aktuellen Stand und den zukünftigen Angeboten von OpenTelemetry begeistert sind. Sie können sich unser Gespräch unten ansehen und in diesem Blog mehr darüber erfahren, warum OpenTelemetry eine große Bereicherung für die Cloud-native- Application ist.

OpenTelemetry ermöglicht Observability 2.0

OpenTelemetry wurde erstmals auf der KubeCon 2019 in Barcelona angekündigt und hat eine Gruppe begeisterter Mitwirkender angezogen. Gemessen an der Anzahl der Beiträge ist es das zweitbeliebteste Projekt der Cloud Native Computing Foundation (CNCF) und in den letzten sechs Monaten war die Beitragsquote höher als je zuvor. Diese große Zahl an Mitwirkenden zeigt, dass OpenTelemetry ausgereift ist und beginnt, die Kluft zwischen Early Adopters (die bereit sind, der Zeit voraus zu sein) und Pragmatikern (die ausgereifte Produkte wünschen) zu überbrücken.

Der Schwerpunkt von OpenTelemetry liegt auf Daten – insbesondere auf den Daten und Datenströmen (Telemetrie), die für das optimale Verständnis, die Fehlerbehebung und die Verbesserung unserer Applications erforderlich sind. Daten sind nur dann nützlich, wenn sie in großem Maßstab aggregiert, analysiert und visualisiert werden können. Zwar bietet OpenTelemetry keine Anleitung zur Visualisierung der Daten, aber wir müssen uns keine Gedanken mehr darüber machen, welche Daten wir erhalten können, und können uns stattdessen darauf konzentrieren, was wir mit den Daten tun können.

OpenTelemetry ermöglicht außerdem eine natürliche Korrelation dieser Datenquellen, statt von uns zu erwarten, dass wir diese Korrelation selbst versuchen. Die Fähigkeit von OpenTelemetry, Ereignisse über Apps hinweg zu korrelieren, führt uns zu Observability 2.0 – einem neuen Maßstab für die Messung der Application in der Cloud. Die Daten sind für uns bereits korreliert, was unsere Sicht auf unseren Application verändert. Wir sind nicht mehr länger darauf beschränkt, nur zu wissen, ob die App läuft oder nicht; wir können jetzt auch den Weg nachvollziehen, den jede Anfrage durch unsere Apps nimmt.

Zwei bemerkenswerte Open-Source-Projekte gingen OpenTelemetry voraus: OpenTracing (OT) und OpenCensus (OC) . Beide haben sich der Herausforderung gestellt, das Format der Trace-Daten zu standardisieren, damit wir die erforderlichen Informationen erhalten und verstehen konnten, welche Auswirkungen diese auf unsere modernen Apps haben. Zwar wiesen die einzelnen Projekte Ähnlichkeiten auf, doch sie konkurrierten um Ressourcen, und die Unternehmen mussten sich häufig für eines entscheiden. Im März 2019 gaben die beiden Projekte ihre Fusion zu OpenTelemetry bekannt, mit dem Ziel, die Generierung und Formatierung von Trace-Daten zu vereinheitlichen. Das OpenTelemetry-Projekt definiert darüber hinaus Standards für die Erfassung anderer Klassen von Beobachtungsdaten ( Metriken und Protokolle ) über dieselben Telemetriekanäle wie Traces, was zu mehr Integration und Klarheit führt.

Als Nächstes schauen wir uns zwei spannende funktionale Aspekte von OpenTelemetry an: verteiltes Tracing und Anwendungsintelligenz .

Warum Distributed Tracing in modernen App-Architekturen erforderlich ist

Obwohl Distributed Tracing bereits seit Jahren existiert, ist der Bedarf daran im letzten Jahrzehnt durch zahlreiche Veränderungen gestiegen. Mithilfe des Cynefin-Frameworks können wir einige der Änderungen und Herausforderungen hervorheben, mit denen wir heute bei modernen Applications konfrontiert sind:

Das Cynefin-Framework veranschaulicht, wie wir unsere Praktiken ändern können, wenn wir vom Einfachen zum Komplexen übergehen. Die Herausforderung besteht darin, dass wir uns auf zwei unterschiedlichen Wegen bewegen, von denen jeder seine eigenen Merkmale aufweist. Der Versuch, eine Abkürzung direkt vom Einfachen zum Komplexen zu nehmen, führt häufig zu Unordnung und unvollständigen Fortschritten.

Lassen Sie uns herausfinden, welche Elemente die Pfade unserer modernen App- und Cloud-native-Reise erstellen. In unserem ersten Pfad (der Y-Achse im Cynefin-Diagramm) haben wir moderne Apps, bei denen es sich normalerweise um Microservices-Architekturen handelt, in denen jede App eine bestimmte Aufgabe erfüllt. Beim zweiten Pfad (der X-Achse) ist unsere komplizierte Umgebung flüchtig, da Microservice-Instanzen je nach Bedarf hoch- und heruntergefahren werden und bei Netzwerkproblemen auf andere Hosts verschoben werden.

Wir müssen auch die Entstehung und das massive Wachstum von Cloud-Umgebungen wie Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP) berücksichtigen. Ein Vorteil solcher Clouds ist die elastische Reaktion – die Erweiterung oder Reduzierung der Ressourcen, um sie der aktuellen Nachfrage anzupassen. Unter den zusätzlichen Auswirkungen der Container-Orchestrierung (am häufigsten mit Kubernetes) kommt es zu chaotischem Verhalten, da sich Anzahl und Standort der Ressourcen im Laufe der Zeit ändern. (Selbst diese relativ eingeschränkte Ansicht ist chaotisch und Elemente wie serverlose Funktionen können das Chaos noch verstärken.)

In einer modernen Architektur mit vielen separaten Teilen, die die Telemetriedaten erzeugen, die wir zur Überwachung und Wartung unserer Apps benötigen, ist die Datenlast enorm und kompliziert. Es kann sein, dass Probleme nicht immer wiederkehren oder nicht leicht zu ermitteln sind, da wir die Infrastruktur und die Kommunikationswege nicht vollständig kontrollieren. Wir benötigen eine Technologie, mit der wir alle Aktivitäten und damit verbundenen Elemente verfolgen können, damit wir unsere sich verändernden Umgebungen verstehen und analysieren können.

Hier kommt OpenTelemetry ins Spiel.

Die Zukunft des Distributed Tracing mit OpenTelemetry

Die verteilte Ablaufverfolgung führt zu großen Veränderungen in der Branche, insbesondere im Hinblick darauf, wie Anfragen über Metriken eine interne Ansicht der Leistung generieren. Mithilfe der verteilten Ablaufverfolgung können wir neue Messgrößen vieler Typen verfolgen, am häufigsten jedoch solche, die sich auf die Anzahl der Anfragen pro Zeiteinheit, die Anzahl der Fehler pro Zeiteinheit und darauf beziehen, wie lange eine aggregierte Anfrage in dieser Zeiteinheit dauert.

Metriken gibt es schon seit einiger Zeit – sie lassen sich einfach verwalten und speichern, leicht aggregieren und eignen sich für mathematische Analysen. In OpenTelemetry können alle Apps, die Metriken generieren, diese über eine Telemetrieschicht (Übertragungsschicht) an einen gemeinsamen Sammelpunkt senden. Dies hilft dabei, die Daten der lose gekoppelten Dienste, die sie generieren, anzugleichen. Hierzu gehört auch die Abstimmung mit der zugrunde liegenden Infrastruktur. Kurz gesagt: Mit OpenTelemetry wird es einfacher, Messdaten zu erfassen und zu senden.

OpenTelemetry kann auch dazu beitragen, das Problem der Zeitstempelabweichung und -verzerrung zu lösen, das die Korrelation von Ereignissen erschwert. OpenTelemetry weist jeder Anforderung eine TraceId zu, die Daten können jedoch immer noch durch Drift und Verzerrung beeinflusst werden, die häufig in Cloud-nativen Architekturen auftreten. Abweichungen und Abweichungen können durch Berichtspfade mit unterschiedlichen Dauern oder durch eine unzureichende Synchronisierung der Uhren auf den verschiedenen Hosts entstehen. Durch die Verfolgung der Kommunikation zwischen Komponenten während der Datenverkehrsverarbeitung ermöglicht verteiltes Tracing OpenTelemetry, einzelne Bereiche (die Arbeitseinheiten und Bausteine eines Tracings) zu messen, ohne dass eine umfassende Instrumentierung der zugehörigen App erforderlich ist.

Durch die Kombination dieser drei Signale (Telemetriekategorien) können wir Probleme beheben und unsere Apps wieder auf Produktionsqualität bringen:

• Kennzahlen – „Gibt es ein Problem?“
• Spuren – „Wo liegt das Problem?“
• Protokolle – „Was ist das Problem?“

Hier kommen wir zurück zu Observability 2.0. Die Möglichkeit, Spuren abzurufen und sofort zu erkennen, welche Messwerte zu welcher Spur gehören, verschafft uns eine enorme Leistungsfähigkeit. Wenn die Metriken beispielsweise auf ein Problem hinweisen, können Sie mit der verteilten Ablaufverfolgung bis zu der spezifischen Anfrage zurückgehen, die das ursprüngliche Problem verursacht hat, und den Fortschritt bei jedem Schritt der Anfrageerfüllung verfolgen. Da unsere Ablaufverfolgung aus den Bereichen in der Reihenfolge besteht, in der sie auftreten, können wir die Anfrage auf jedem Schritt ihres Weges verfolgen. Wenn wir wissen, was in welcher Reihenfolge passiert ist – vom ursprünglichen Ereignis über das angezeigte Problem bis hin zum Endergebnis –, können wir unsere Aufmerksamkeit gezielt darauf richten, worauf wir in unseren Apps achten.

So einfach es auch klingen mag, der verteilte Ablaufverfolgungsaspekt von OpenTelemetry kann uns großartige Einblicke in die Erfahrungen unserer Benutzer verschaffen, da er als Indikator für den Anforderungserfolg und den Ausführungszeitpunkt dient. Als Nutzer liegt mir mein Anliegen am Herzen. Als Site Reliability Engineer (SRE) kümmere ich mich um die aggregierten Anfragen. OpenTelemetry bietet mir beides und darüber hinaus die Möglichkeit, von aggregierten Daten zu spezifischen Daten zu gelangen, da es darauf ausgelegt ist, alle benötigten Daten in allen Apps verfügbar zu machen.

Anwendungsintelligenz mit KI und ML

Dieser neue Datenstrom von OpenTelemetry ermöglicht es uns außerdem, bei unserer Entwicklung und unseren operativen Reaktionen anpassungsfähig und automatisiert zu sein. Mit all diesen gesammelten Daten können wir unsere Application intelligenter machen. F5 konzentriert sich derzeit darauf, unsere Kunden bei der Entwicklung und Bereitstellung dessen zu unterstützen, was wir „ adaptive Applications “ nennen. Adaptive Apps sind genau das, wonach sie sich anhören: Applications , die ihr Verhalten automatisch und intelligent als Reaktion auf Änderungen in ihrer Umgebung anpassen.

Aus diesem Grund kommen in verschiedenen Lösungen immer mehr Künstliche Intelligenz (KI) und maschinelles Lernen (ML) zum Einsatz. Aber der Grund liegt nicht nur darin, dass es sich um Trendbegriffe handelt – KI und ML sind auch deshalb nützlich, weil wir heute über genügend Daten verfügen, um genaue Schlussfolgerungen zu Kausalitäten zu ziehen und entsprechende Maßnahmen zu entwickeln.

Indem OpenTelemetry Telemetriedaten zugänglich und standardisiert macht, erleichtert es den Weg zu adaptiven Apps erheblich. Da verschiedene Produkttypen beginnen, ähnliche Messwerte auszugeben, und durch die Nutzung der etablierten semantischen Konventionen innerhalb von OpenTelemetry wird es einfacher, ihre Aktionen während der Anforderungsverarbeitung zu korrelieren und diese Informationen an ML- und KI-Algorithmen weiterzuleiten, um eine dynamische Anpassung von Applications und Infrastruktur zu ermöglichen.

Wenn Sie die Datenwissenschaft dahinter verstehen und sicherstellen, dass Ihre Telemetriedaten mit Ihrer KI und Ihrem ML in Zusammenhang stehen, kann sich die datengesteuerte Natur adaptiver Apps weiterentwickeln und entfalten.

Zusammenfassung

Die Kodierung der Telemetrie ist sowohl für die Benutzer von OpenTelemetry als auch für die Applications , die es als Telemetriekanal verwenden, ein klarer Gewinn. Daten können aus mehreren Quellen gesammelt und an alle kompatiblen Aggregations- und Analysetools weitergeleitet werden. Darüber hinaus befreit der OpenTelemetry Collector die Anbieter von der Notwendigkeit, Collector selbst zu implementieren. Stattdessen können sie sich auf die Verbesserung ihres Codes konzentrieren, um aussagekräftige Analysen und intelligente Aktionen durchzuführen. Außerdem können sie neue Tools entwickeln, die ihnen beim Verständnis dieser komplexen und chaotischen neuen Welt helfen. Tatsächlich ist der OpenTelemetry Collector – unterstützt durch die Innovation von Open Source – immens in der Lage, mit nahezu jedem vorhandenen Format zu arbeiten und gleichzeitig die Technologie in die Zukunft zu führen.

Durch den Fokus auf die wichtigsten Datenklassen, die wir zum Verständnis unserer Applications benötigen, ermöglicht OpenTelemetry unseren Apps, tiefere Einblicke sowohl in die Leistung als auch in die Probleme unserer komplexen modernen Application zu bieten. Durch die Korrelation unserer Daten und die Ausrichtung an semantischen und Standardkonventionen macht OpenTelemetry den Weg zu modernen Applications einfacher. Und während das Projekt immer weiter reift und die Akzeptanz weiter zunimmt, ist OpenTelemetry der klare Ansatz für unser tieferes Verständnis und unsere Fähigkeit, KI- und ML-Techniken anzuwenden, um diese Komplexität verständlich zu machen.

Um mehr darüber zu erfahren, wie die OSS-Ingenieure von NGINX OpenTelemetry verwenden, probieren Sie die Modern Apps Reference Architecture und die Application (Bank of Sirius) aus.

Verwandte Artikel

• Drei Schritte zum Start Ihrer Cloud-Native-Reise mit Kubernetes