Als Observability-Praktiker haben wir natürlich Fragen, die nur Telemetriedaten wirklich beantworten können. Bei der Betrachtung eines Systems ist es hilfreich, sowohl einen Überblick über das System zu haben (wie ist beispielsweise die Leistung der Zahlungsfunktion) als auch detaillierte Fragen beantworten zu können (beispielsweise bei welchen Kund:innen die Zahlung zu lange dauert). Ich nenne diesen Vorgang gerne „Heranzoomen“, da wir uns zunächst die Daten auf hoher Ebene ansehen und dann tiefer in die Einzelheiten einsteigen.
Durch die Verwendung der New Relic Query Language (NRQL) zusätzlich zu MELT-Daten (Metriken, Events, Logs und Traces, die von New Relic Agents, OpenTelemetry, Prometheus und vielen mehr gesammelt wurden) können wir schnell Einblicke in laufende Systeme gewinnen. Mit einer einzigen Abfragesprache können wir uns einen Überblick verschaffen und die Abfrage anschließend weiter verfeinern, um die Daten aus bestimmten Blickwinkel zu betrachten.
Sehen wir uns anhand eines Beispielsystems an, wie wir auf diese Weise wichtige Einblicke gewinnen können.
Aus der Vogelperspektive
Als Grundlage meiner Analyse verwende ich heute Tracing-Telemetriedaten, die aus einer OpenTelemetry-Anwendung stammen. Dabei handelt es sich um eine E-Commerce-Anwendung, die über einen Frontend-Service und einige Backend-Microservices verfügt, wie in der Abbildung unten dargestellt.
Die Seiten zum Application Performance Monitoring (APM) bieten einen allgemeinen Überblick mit Schwerpunkt auf dem Service. Wir können jedoch genauere Einblicke gewinnen, indem wir unsere eigene NRQL-Abfrage für dieselben Daten schreiben, die den Diagrammen in APM zugrunde liegen.
Weiter ins Detail mit Query Builder und NRQL
Um mehr über den laufenden Service zu erfahren, möchten wir uns einen Überblick über die Traces verschaffen. Ein Beispiel für eine einfache Abfrage wäre die nachstehende, um mithilfe des Query Builders einen Eindruck davon zu bekommen, welche Trace-Zusammenfassungsdaten für den Frontend-Service vorhanden sind:
FROM DistributedTraceSummary SELECT *
WHERE root.entity.name = 'frontend-otel'SELECT *-Abfragen, wie in der folgenden Abbildung dargestellt, geben einen guten Überblick darüber, welche Attribute vorhanden sein könnten, indem die letzten 100 Datenzeilen ausgewählt werden. duration.ms ist offensichtlich ein Attribut, das mir sagen könnte, wie lange diese Frontend-Transaktionen in Millisekunden gedauert haben.
Beim Plotten von Latenzdaten ist es besser, die Verteilung der Werte zu betrachten und nicht etwa den Durchschnitt. Ich wähle zusätzlich zur Anzahl der Traces vom letzten Datentag die Perzentile 50, 90, 95 und 99 aus:
FROM DistributedTraceSummary SELECT percentile(duration.ms, 50, 90, 95, 99), count(*)
WHERE root.entity.name = 'frontend-otel'
SINCE 1 day ago
Das resultierende Diagramm zeigt Perzentile für duration.ms und die Trace-Anzahl für den letzten Tag.
Dies ist eine brauchbare grobe Übersicht. Es finden viele Transaktionen statt. Dies könnte ein gutes Ziel für ein Übersichts-Dashboard sein, aber ich möchte vielleicht etwas tiefer gehen.
In die Daten hineinzoomen
In unserer Beispielanwendung haben wir eine Zusammenfassung des Frontend-Service, wissen aber nicht, wie die Abhängigkeiten des Service funktionieren.
Als Erstes müssen die anderen Services ermittelt werden, die zur Latenz des Frontend-Service beitragen. Um diese Detailtiefe zu erreichen, verwenden wir das Tracing-Span-Event, das eines der „Atome“ eines Distributed Trace ist.
Um zu den Services zu gelangen, die dem Frontend zugrunde liegen, können wir einen Satz von Beispiel-Traces abrufen und dann die Servicenamen in den Span-Daten suchen. Dies wird durch die folgende NRQL-Abfrage erreicht:
FROM Span SELECT uniques(service.name)
WHERE trace.id in (FROM DistributedTraceSummary SELECT trace.id WHERE root.entity.name = 'frontend-otel' LIMIT MAX) Die folgende Abbildung zeigt eine Aufschlüsselung der an der Bereitstellung des Frontends beteiligten Services.
Sie werden feststellen, dass darin alle Services in der Aufrufkette enthalten sind, nicht nur der unmittelbare Satz an Services. Dies sind gute Informationen für jede Art von Latenzuntersuchung.
Wir können zu diesem Satz von Spans einige allgemeine Statistiken sammeln, um zu sehen, welche davon die größte Latenz aufweisen, die sich auf das Frontend auswirken könnte. Ich kann die FACET-Klausel verwenden, um Spans nach ihrem Servicenamen zu gruppieren:
FROM Span SELECT percentile(duration.ms, 99), count(*)
WHERE trace.id in (FROM DistributedTraceSummary SELECT trace.id WHERE root.entity.name = 'frontend-otel' LIMIT MAX)
FACET service.nameDas folgende Bild zeigt die Zeitspannen der einzelnen Services.
Dieses Abfrageergebnis zeigt uns, dass der Zahlungsservice ein wichtiger Service ist, den wir im Auge behalten sollten. Nach unserem Kenntnisstand über das System ist er zudem geschäftskritisch, da die E-Commerce-Site ihr Geld mit der Kaufabwicklung verdient.
Zoomen wir wieder heraus und betrachten nur die Spans für den Zahlungsservice, um zu sehen, ob es zusätzliche Erkenntnisse darüber gibt, wo möglicherweise die größte Latenz auftritt:
FROM Span SELECT *
WHERE service.name = 'checkoutservice-otel'Die obige Abfrage isoliert Spans vom Zahlungsservice, wie in der folgenden Abbildung gezeigt.
Mir ist aufgefallen, dass das name-Attribut den Endpunkt innerhalb des aufgerufenen Service hat. Schauen wir uns diejenigen an, die FACET verwenden.
FROM Span SELECT percentile(duration.ms, 95, 99)
WHERE service.name = 'checkoutservice-otel'
FACET nameDiese Abfrage zeigt die jeweilige Transaktionsdauer nach Endpunkt innerhalb des Zahlungsservice.
Bevor wir fortfahren, können diese Namen etwas bereinigt werden, sodass nur der Teil nach dem „oteldemo“-Präfix zusammen mit TIMESERIES MAX enthalten ist, damit die Latenzperzentile im Zeitverlauf angezeigt werden:
WITH aparse(name, 'oteldemo.*') as sanitizedName
FROM Span SELECT percentile(duration.ms, 95, 99)
WHERE service.name = 'checkoutservice-otel'
FACET sanitizedName TIMESERIES MAXMit vereinfachten Namen und im Zeitverlauf angezeigten Perzentilen erleichtert die obige Abfrage das Erkennen von Endpunkten mit ungewöhnlichen Trends hinsichtlich der Dauer.
Aus diesem Diagramm geht klar hervor, dass „PlaceOrder“ aus der Masse hervorsticht. Beschränken wir unsere Abfragen auf diesen Endpunkt und betrachten wir einen längeren Zeitraum nur mit p95:
WITH aparse(name, 'oteldemo.*') as sanitizedName
FROM Span SELECT percentile(duration.ms, 95)
WHERE service.name = 'checkoutservice-otel' and sanitizedName = 'CheckoutService/PlaceOrder'
TIMESERIES MAX since 1 week agoDie Abfrage gibt den Wochentrend für den Endpunkt „PlaceOrder“ zurück, wie in der folgenden Abbildung dargestellt.
Dies gibt uns ein gutes, interessantes Signal. Es sieht so aus, als ob es am 18. Oktober um 17:30 Uhr zu einer Latenzspitze kam. Mit dem Query Builder kann ich in diesen bestimmten Zeitrahmen hineinzoomen:
Um wirklich zu wissen, warum dies eventuell passieren geschieht, finden Sie die Details in den spezifischen langsamen Spans. Schauen wir uns nur Spans an, die eine Dauer von mehr als 1 Sekunde (1000 Millisekunden) aufweisen:
WITH aparse(name, 'oteldemo.*') as sanitizedName
FROM Span SELECT duration.ms, *
WHERE service.name = 'checkoutservice-otel' AND sanitizedName = 'CheckoutService/PlaceOrder' AND duration.ms > 1000
since '2024-10-18 01:25:00+0530' UNTIL '2024-10-18 09:52:00+0530'Diese Abfrage isoliert Spans mit einer Dauer von mehr als 1 Sekunde, sodass Sie mögliche Bottlenecks detaillierter untersuchen können.
Von hier aus kann es eventuell ein Signal im Bestellbetrag oder andere Informationen geben, die eine neue Theorie darüber liefern könnten, warum dieser Aufruf möglicherweise langsam war und was im Servicecode dagegen zu tun ist.
Fazit
Die Fähigkeit, durch Daten zu navigieren und heran- sowie herauszuzoomen, um ein tieferes Verständnis zu erlangen, ist eine Kernkompetenz von Observability-Profis. Sie hilft dabei, das Verhalten eines Systems zu verstehen und mögliche Probleme zu identifizieren. Die Möglichkeit, mit einem kleinen NRQL-Snippet zu beginnen, um sich einen groben Überblick über die Daten zu verschaffen, und dann anhand der wichtigen Attribute Ihrer Daten in die Einzelheiten hineinzuzoomen, ist einer der leistungsstarken und zugleich reizvollen Aspekte der Datenerkundung mit New Relic.
Nächste Schritte
Sind Sie bereit, in die komplexe Welt der Telemetrie einzutauchen? Registrieren Sie sich kostenlos für New Relic und beginnen Sie mit der Erkundung von Telemetriedaten. Sehen Sie sich unsere Dokumentation an, um mehr über NRQL zu erfahren.
Die in diesem Blog geäußerten Ansichten sind die des Autors und spiegeln nicht unbedingt die Ansichten von New Relic wider. Alle vom Autor angebotenen Lösungen sind umgebungsspezifisch und nicht Teil der kommerziellen Lösungen oder des Supports von New Relic. Bitte besuchen Sie uns exklusiv im Explorers Hub (discuss.newrelic.com) für Fragen und Unterstützung zu diesem Blogbeitrag. Dieser Blog kann Links zu Inhalten auf Websites Dritter enthalten. Durch die Bereitstellung solcher Links übernimmt, garantiert, genehmigt oder billigt New Relic die auf diesen Websites verfügbaren Informationen, Ansichten oder Produkte nicht.
