Schnellere Fehlerbehebung im Application Stack mit OpenTelemetry und New Relic One

OpenTelemetry provides community-contributed instrumentation that standardizes telemetry data collection from your applications and services, without vendor lock-in. With OpenTelemetry tracing already stable and metrics stability fast approaching, New Relic now provides an enhanced OpenTelemetry offering that includes support for OpenTelemetry Protocol (OTLP) over HTTP/1.1 and infinite tracing along with curated experiences for the ingested data. This offering enables faster troubleshooting and provides a seamless transition to OpenTelemetry.

So nutzen Sie OpenTelemetry und New Relic One

Testen Sie OpenTelemetry einfach direkt mit Ihren eigenen Anwendungen und Services. Damit instrumentieren Sie Komponenten, die Sie bereits bestens kennen, und profitieren rascher von den Vorteilen von OpenTelemetry. 

Ein alternativer Ansatz besteht in der Nutzung unserer Fork für die cloudnativen Microservices zu Online Boutique als Demo-Anwendung oder eines der New Relic OpenTelemetry Beispiele.  

Erster Schritt: Datenerfassung

Nach Instrumentierung Ihrer Services mit der OpenTelemetry SDK/API können Sie Ihre Daten mit New Relic One über unseren nativen OTLP-Endpunkt erfassen. Hierfür sind folgende Schritte vonnöten:

1. Weisen Sie idealerweise Ihrem OTLP oder alternativ Ihrem OTLP/HTTP-Exporter den zugehörigen New Relic OTLP-Endpunkt zu: otlp.nr-data.net:4317 oder https://otlp.nr-data.net:4318.

2. Fügen Sie das Header-Attribut „api-key“ hinzu. Bei seinem Wert handelt es sich um den Account License Key für das New Relic Konto, an das Sie Ihre Daten senden möchten. 

Falls Sie einen OpenTelemetry Collector nutzen, wird das in der Datei otel-config.yaml in etwa so aussehen:

Alternativ können Sie auch den OTLP/HTTP-Exporter verwenden:

Weitere Informationen finden Sie in der OpenTelemetry Quickstart-Dokumentation.

OpenTelemetry Daten über New Relic One einsehen

Ihre Anwendung überträgt nun OpenTelemetry Daten an New Relic One. Einsehen können Sie diese nun über eine dynamische UI, anhand derer Sie Metrics wie Reaktionszeit, Fehlerrate und Throughput gruppieren, facettieren und filtern können, dies für jede Datendimension der OpenTelemetry Attribute (service.version, http.status_code, thread.name etc.). Zu dieser UI gehören auch kuratierte Ansichten von Datenbanken, Transaktionen, Fehlern und Distributed Tracing, die im Zuge der Fehlerbehebung sehr nützlich sind. Im Folgenden gehen wir anhand der Demo-App für Microservices auf einige Szenarien ein, bei denen sich diese Möglichkeiten mit OpenTelemetry in jedem Engineering-Kontext als höchst probate Hilfsmittel erweisen. 

Umgebungsmonitoring

DevOps-Entwickler:innen und Engineering-Teams mit operativem Fokus allgemein müssen alle Abläufe in ihrer Gesamtumgebung regelmäßig genau prüfen. Im New Relic Explorer finden Sie alle OpenTelemetry Daten stets zentral vor, dies ganz ohne separate Konfiguration. Erkennen Sie Probleme bereits in der Entstehung in Echtzeit, ohne sich auf statische, vorkonfigurierte Thresholds oder Dashboards verlassen zu müssen: Wichtige Systemänderungen werden accountübergreifend dargestellt, sind in Kombination mit dem Health-Status Ihrer Umgebung sofort nachvollziehbar. Etwaige Probleme lassen sich so viel direkter abbilden, analysieren und lösen. New Relic Explorer bietet verschiedene Konzepte zur Visualisierung und Analyse Ihres Systems:

• New Relic Lookout vermittelt eine Echtzeit-Ansicht aller Accounts, macht Änderungen an Ihrer Telemetrie ohne Konfigurationsaufwand über eine klar strukturierte Benutzeroberfläche sichtbar. Intuitive Visualisierungen in Form von Farb- und Grafikschemata bilden Ausmaß und Relevanz aller Telemetrie-Themen ab und werfen das Schlaglicht auf die Zusammenhänge, die direkt Ihrer Aufmerksamkeit bedürfen.
• Mit New Relic Navigator verifizieren Sie rasch den Health-Status Ihrer OpenTelemetry Services über alle Konten hinweg, dies anhand spezifischer, tag-basierter Entitätsgruppen. Services mit Problemen können Sie bei Bedarf dann ganz einfach genauer prüfen. Im folgenden Screenshot sind Alerts für mehrere OpenTelemetry Services zu sehen.  

Allein anhand dieser Visualisierung ist aber immer noch nicht klar erkennbar, wie diese Services genauer in Verbindung zueinander stehen. Was also, wenn Sie über diese überblicksartige Ansicht hinaus die Services und Abhängigkeiten in Ihrer verteilten Architektur visualisieren möchten? 

Dafür gibt es Automaps, mit denen Sie Performance-Probleme rasch klar korreliert ausmachen. Über sie und Entitäten-Widgets identifizieren Sie Health-Probleme in anderen Services und können einsehen, wie diese mit Ihren Infrastrukturkomponenten zusammenhängen.  

Die Automap für den FrontEnd-Service im folgenden Screenshot zeigt Abhängigkeiten von fünf weiteren Services auf, so etwa dem AdService. Generell bieten Automaps einen Tracing-Pfad hin zur Fehlerursache.

Fehlerbehebung

Basierend auf den Thresholds, die Sie über den OpenTelemetry Service konfiguriert haben, können Sie auch Alerts erstellen, um von diesen ausgegebene Fehler dann direkt zu beheben. Mittels farbcodierten Statusindikatoren zu diesen OpenTelemetry Services im New Relic Explorer sowie im Activity Stream lassen sich Details und Schweregrad ablesen.

Im vorhergehenden Screenshot ist ersichtlich, dass für AdService ein kritischer Verstoß vorliegt. Laut Activity Stream befindet sich die Fehlerrate über dem Threshold.  Werfen wir einen Blick auf die Traces mit Fehlern. 

Beim Klick auf eine der Fehler-Traces wird oben eine zugehörige Trace Map eingeblendet (siehe Screenshot). Trace Maps helfen Ihnen bei der Visualisierung aller Services, die bei der Ausführung einer Abfrage (Trace) involviert sind, dies zusammen mit den einzelnen Spans. Für jede Entität werden beim Mouseover umfassende Detaildaten im Trace-Kontext angezeigt. Über die Fehlerdetails können Sie zudem die Ursache klar identifizieren, auch anhand von über die OpenTelemetry Instrumentierung generierten Stack-Traces. Die Fehlerdetails werden auf Basis von nach OpenTelemetry Specs erfassten Span-Events ausgegeben. Die zusätzlichen Fehlerdetails lassen sich wie im nachfolgenden Screenshot über den rot umrandeten UI-Bereich einsehen.

Neben Fehler-Tracing ist auch die Erfassung von Logs als Span-Events möglich. Ihre Anwendungslogs lassen sich über jeden unterstützen Log Forwarder auch direkt an New Relic One übermitteln, um die Performance Ihrer Services mit den zugehörigen Logs zu korrelieren. Mit Logs in Context gelangen Sie direkt in die für Sie relevanten Log-Zeilen und adressieren Probleme schneller (siehe Screenshot). 

New Relic OpenTelemetry UI: Entwicklung mit langfristiger Perspektive

Mit der fortlaufenden Entwicklung von OpenTelemetry erweitern wir auch unsere Unterstützung für OpenTelemetry in New Relic One. In diesem Zuge möchten wir Entwickler:innen alle Möglichkeiten von New Relic One an die Hand geben – unabhängig von der Instrumentierungsquelle. So haben Sie rascher Zugriff auf alle Daten, die Sie zur Behebung von Fehlerursachen sowie zur Performance-Optimierung für Ihre Anwendungen und Services benötigen. 

Auch über Ihr Feedback zu New Relic One und OpenTelemetry freuen wir uns natürlich. Übermitteln Sie es uns gerne jederzeit über die zugehörige Schaltfläche im oberen Navigationsbereich in New Relic One.

Sie haben noch kein Konto für New Relic One? Dann starten Sie direkt hier. Mit dem Einstiegskonto übermitteln Sie jeden Monat 100 GB an OpenTelemetry Daten komplett kostenlos.