Holen Sie mit New Relic mehr aus Ihren OpenTelemetry-Daten heraus

Einleitung

Vor Kurzem haben wir die allgemeine Verfügbarkeit der New Relic APM + OpenTelemetry Convergence bekannt gegeben. Das bedeutet, dass unsere Plattform jetzt ein erstklassiges Observability-Erlebnis für Ihre OpenTelemetry(OTel)-Daten bietet.

Da OTel selbst ein Framework zur Datenerfassung und kein Observability-Backend ist, ist die Instrumentierung nur der erste Implementierungsschritt. Das Projekt konzentriert sich auf die Frage, wie Telemetrie generiert werden kann, nicht aber, was damit zu tun ist. Um aus den von OTel erzeugten Rohdatenströmen umsetzbare Einblicke zu gewinnen, benötigen Sie eine hochentwickelte, skalierbare und intelligente Plattform zum Erfassen, Speichern, Korrelieren und Visualisieren dieser Daten. 

Genau hier setzt New Relic an. In diesem Blogpost verwenden wir den New Relic Fork der OpenTelemetry-Beispielanwendung, den Astroshop, um zu zeigen, wie New Relic Ihnen hilft, Ihre OTel-Daten voll auszuschöpfen. 

Deployment des Astroshops

Der Astroshop ist ein auf Microservices basierendes verteiltes System, das von der OTel-Community in mehreren Sprachen erstellt wurde, um die Implementierung von OTel in einer nahezu realen Umgebung zu zeigen. New Relic unterhält einen Fork dieser Demoanwendung. Um die Lücke zwischen Instrumentierung und Einblicken zu schließen, haben wir unseren Fork vorkonfiguriert, um den Einrichtungsprozess zu optimieren und es Ihnen zu ermöglichen, fast sofort Daten an Ihr New Relic Konto zu senden.

Der Astroshop ist außerdem mit Feature-Flags ausgestattet, die Sie aktivieren und deaktivieren können, um eine Vielzahl praxisnaher Softwareprobleme zu simulieren. In dem Beispiel, das wir in diesem Blogpost verwenden, wurde das Feature-Flag „productcatalogfailure“ aktiviert, was bedeutet, dass für GetProduct-Anfragen mit einer bestimmten Produkt-ID ein Fehler generiert wird. 

Das Deployment der Demoanwendung ist einfach. Vergewissern Sie sich, dass Ihre Umgebung die Voraussetzungen erfüllt, klonen Sie den Fork, und stellen Sie dann den Astroshop lokal mit Kubernetes oder Docker bereit. Als Nächstes validieren Sie Ihr Deployment, und dann können wir Ihre Daten untersuchen.

Mehr zu sehen in der New Relic UI

Sobald die verschiedenen Astroshop-Microservices mit der Datenübermittlung beginnen (bitte warten Sie nach dem Deployment einige Minuten, bis die Entities synthetisiert sind), können Sie sie alle in Ihrer Entities-Ansicht sehen. Navigieren Sie in Ihrem New Relic Konto zu APM & Services, klicken Sie auf Services – OpenTelemetry und dann auf „View all“.

Hinweis: Sie werden feststellen, dass nicht alle Services Daten zu Antwortzeit, Throughput und Fehlerquote melden. Dies hat zwei Gründe:

• Die APM + OTel Convergence stützt sich auf Metrikdaten, die bisher noch nicht von allen Services gemeldet werden.
• Das OTel-Projekt hat in den Sprach-SDKs und APIs unterschiedliche Implementierungsstufen, was sich auf die Instrumentierung der Metriken in einigen Services ausgewirkt hat. 

Die APM + OTel UI Convergence soll die erstklassige APM-Erfahrung von New Relic auf OTel-Datenquellen übertragen. Der Kernmechanismus dieser Technologiekonvergenz ist ein Prozess der intelligenten Datennormalisierung: Wenn standardmäßige OTel-Daten an den New Relic OTLP-Endpunkt gesendet werden, erstellt die Plattform automatisch eine normalisierte Kopie dieser Daten und passt sie an unsere soliden und ausgereiften semantischen APM-Konventionen an. Dieser Prozess ist völlig zerstörungsfrei; die ursprünglichen OTel-Quelldaten bleiben erhalten und stehen für Abfragen zur Verfügung, wodurch vollständige Datengenauigkeit gewährleistet wird. 

Diese automatische UI-Auffüllung ist kein Hexenwerk; sie ist das direkte Ergebnis der Einhaltung der von OTel definierten und von der New Relic Plattform erkannten semantischen Konventionen. New Relic verwendet spezifische Ressourcenattribute, die an die Telemetriedaten angehängt sind, um Entities zu synthetisieren, den Prozess der Identifizierung, Klassifizierung und Erstellung von Entities wie Services, Hosts und Datenbanken innerhalb der UI.

In der folgenden Tabelle sind mehrere wichtige Attribute und die spezifischen New Relic Funktionen aufgeführt, die sie ermöglichen:

Die UI der APM + OTel Convergence

Nachdem Sie nun einen ersten Eindruck davon haben, was hinter den Kulissen vor sich geht, schauen wir uns Ihre Astroshop-Daten genauer an. Für dieses Beispiel wählen wir den Service product-catalog aus. Wenn Sie auf eine Entity klicken, gelangen Sie zur Übersicht für diese Entity. 

Wenn Sie ein wenig nach unten scrollen, sehen Sie unter Errors das Fehlerdiagramm und unter Transactions die Transaktionsliste. Die Transaktion namens grpc/oteldemo.ProductCatalogService.GetProduct weist eine Fehlerquote von über 4 % auf.

Wenn Sie bei der GetProduct-Transaktion auf die Schaltfläche „View details“ klicken, wird die neue Ansicht Transaction 360 angezeigt, die die standardmäßige Einzel-Trace-Analyse erweitert und Ihnen eine dynamische Ansicht des gesamten Transaktionsökosystems bietet. Mithilfe dieses Features erhalten Sie auf einen Blick Informationen zur Anwendungs- und Infrastruktur-Performance, einschließlich aktiver kritischer Alerts und neuer Deployment-Versionen (innerhalb des ausgewählten Zeitfensters). Der Kontext ermöglicht es Ihnen, Probleme direkt mit dem jeweiligen Deployment, Host oder Service zu korrelieren. 

Diese Ansicht enthält die neue dynamische Flow Map, auf der Sie sehen können, wie die Trace-Daten durch die Services fließen. Sie verwendet die Trace-Daten, um Performance-Änderungen zwischen vor- und nachgelagerten Entities im Verhältnis zum vorherigen übereinstimmenden Zeitfenster zu korrelieren. 

Wenn Sie durch die Ansicht scrollen, werden Ihnen unter Participating APM services Informationen zu beteiligten APM-Services sowie zu Transaktionen angezeigt, die an dem Trace beteiligt waren.

Da die GetProduct-Transaktion als Ursache des Problems angegeben wird, gehen wir noch weiter ins Detail, indem wir auf grpc/oteldemo.ProductCatalogService.GetProduct klicken. Dadurch wird eine weitere Ansicht für Transaction 360 mit ein paar Tabs im oberen Bereich geöffnet.

Wenn Sie den Tab „See errors“ auswählen, werden weitere Informationen angezeigt, unter anderem wie oft dieser Fehler aufgetreten ist. Im Abschnitt Deployment des Astroshops haben wir erwähnt, dass das Feature-Flag „productCatalogFailure“ im Beispiel für diesen Blogpost aktiviert wurde. Die Meldung für diese Fehlergruppe lautet „Error: Product Catalog Fail Feature Flag Enabled“ (Fehler: Feature-Flag „Product Catalog Fail“ aktiviert), was genau das ist, was wir erwartet hatten. 

Hinweis: Wenn Sie sich fragen, warum das Fehlerquotendiagramm trotz eindeutiger Fehler keine Daten anzuzeigen scheint: Das liegt daran, dass in diesem Diagramm speziell nach HTTP-Statuscodes von 500 oder weniger gesucht wird. (Wenn Sie bei einem der Diagramme auf „…“ klicken, wird ein Menü mit mehreren Optionen angezeigt. Bei Auswahl von „View query“ wird Ihnen genau die Abfrage angezeigt, die zum Generieren der Daten für dieses Diagramm verwendet wurde.)

Wenn wir diese Drilldown-Ansicht verlassen und zur ursprünglichen Ansicht Transaction 360 zurückkehren, auf die wir über die Übersichtsseite Summary zugegriffen haben, können wir auf den Dropdown-Pfeil klicken, um „Supporting infrastructure entities“ zu öffnen und uns eventuelle Auswirkungen anzusehen.