Ausnahmslos alle Telemetriedaten – Metrics, Events, Traces, Logs und mehr – komplett zentral. Der erste und so wichtige Schritt hin zu Observability für den Gesamt-Stack. Selbst die besten Datenbank-Tools zur Quantifizierung und Messung von Metrics sind nur halb so viel wert, wenn die Daten zu Health und Performance von Anwendungen und Systemen als verstreutes Stückwerk kein schlüssiges Gesamtbild zulassen.

New Relic Query Language (NRQL) macht Datenanalysen aus ganz unterschiedlichen Blickwinkeln möglich – und so enorm vielschichtige Insights, mit ihrem neuesten Upgrade umso mehr. Mithilfe von Unterabfragen lassen sich Daten aus verschiedenen Datenquellen und Zeitbereichen konsolidiert in einer Abfrage verknüpfen. Im folgenden Artikel und live in Aktion in diesem Video erfahren Sie, wie Sie mit Unterabfragen detailliertere Insights für Ihren Gesamt-Stack generieren.

Was ist eine Unterabfrage?

Bei einer Unterabfrage handelt es sich um eine NRQL-Abfrage, die in eine andere Abfrage eingebettet ist. Jede Unterabfrage wird ausgewertet, das Ergebnis dann bei der Ausführung der äußeren Abfrage verwendet. Per Nesting einbetten bzw. schachteln lassen sich bis zu drei Ebenen an Unterabfragen. Die folgende Abfrage etwa gibt alle Transaktionen mit überdurchschnittlicher Dauer aus:

FROM Transaction SELECT count(*) WHERE duration > (
	FROM Transaction SELECT average(duration)
)

Bei einer durchschnittlichen Transaktionsdauer von 30 ms würde die Abfrage wie folgt lauten:

FROM Transaction SELECT count(*) WHERE duration > 30

Hierfür wäre in der Vergangenheit zunächst eine Abfrage zur Bestimmung des Durchschnitts notwendig gewesen – und dann die manuelle Eingabe dieses Durchschnitts in eine Folgeabfrage.

Ihre Daten unisono im Gleichschritt: Beispiele für Unterabfragen

Um die Möglichkeiten moderner Observability-Technologien ausschöpfen zu können, sind Telemetriedaten zu allen Services unabdingbar. Je mehr Datenquellen jedoch Teil des Monitoring-Stacks sind, desto komplizierter wird es auch, mit diesen ein klares, umfassendes Bild der Anwendungs-Performance zu zeichnen. Durch Nutzung von Unterabfragen lässt sich dieses Dilemma in verschiedensten Use Cases adressieren. Im Folgenden gehen wir auf einige gewinnbringende Beispiele ein:

Anwendungsfehler und -Performance: Entitätsdaten als Brücke zu mehr Klarheit

Eine Entität kann jedes Element Ihrer Telemetriedaten sein, das über eine eindeutige Entitäts-ID verfügt und Daten an New Relic weiterleitet oder Daten enthält, auf die New Relic zugreifen kann. Bei den meisten Entitäten verfügt die ID über das Attribut entityGuid.

Die beispielhafte NRQL-Unterabfrage im Folgenden vergleicht die durchschnittliche Dauer für mehrere Anwendungsservices, bei denen kürzlich Fehler aufgetreten sind. Damit soll evaluiert werden, wie Transaktionsfehler die Dauer der Anwendungsausführung beeinflussen. Das Beispiel zeigt, wie die IN-Clause zur Verknüpfung von Identifikatoren aus zwei unterschiedlichen Datenquellen genutzt werden kann.

Hier nun die Abfrage dazu:

FROM Transaction SELECT average(duration) WHERE entity.guid IN (
	FROM TransactionError SELECT uniques(entity.guid)
)FACET appName TIMESERIES

Identifikation von Trends in mehreren Zeitbereichen

Eine weitere enorm hilfreiche Möglichkeit von Unterabfragen findet sich im Vergleich von Daten für mehrere Zeitbereiche. So liefert das Feature COMPARE WITH noch interessantere und detailliertere Vergleichsoptionen. Hier ein Beispiel:

FROM Transaction SELECT average(duration)-(
	FROM Transaction SELECT average(duration)SINCE 1 day AGO
) TIMESERIES 5 minutes SLIDE BY MAX

Diese Abfrage berechnet die Durchschnittsdauer aller Transaktionen am Vortag und gibt dann das Zeitreihendelta der letzten Stunde als Ergebnis aus. SLIDE BY wird nur zur Diagrammglättung verwendet. Diese Abfrage bildet performative Systemabläufe im Vergleich zu gestern ab und mit ihnen wichtige Insights zu aktuellen Trends. Im Beispiel im Screenshot zeigt sich eine sehr gute Systemstabilität mit geringen Abweichungen im Bereich weniger Nanosekunden, was natürlich nicht immer der Fall ist.

Datenverknüpfung mit Logs

Logs liefern uns äußert nützliche Informationen. Mit New Relic Logs in Context lassen sich dabei effizient Daten aus Anwendungen, Serverless-Infrastruktur und Kubernetes-Clustern analysieren. Über NRQL-Unterabfragen erschließen sich nun zudem auch die Zusammenhänge zwischen Transaktionen und Logs.

FROM Log SELECT * WHERE hostname = (
	FROM Transaction SELECT latest(host) WHERE containerId = 'insertcontainerid'
) AND level = 'ERROR'

Im eben gezeigten Beispiel werden Transaktionen abgefragt, um eine bestimmte containerId mit einem Host und zugehörigen Fehler-Logs in Verbindung zu bringen. Unterabfragen machen diese Kontext-Verknüpfungen einfach, ganz ohne separates manuelles Abfragen oder Kopieren von Werten. Auch lassen sich damit Transaktionen aus Hosts mit Log-Fehlern abrufen, wie in dieser Abfrage ersichtlich:

FROM Transaction SELECT * WHERE hostname = (
	FROM Log SELECT latest(host) WHERE level = 'ERROR'
)

Verknüpfung von Transaktionen und Spans mit geschachtelten Unterabfragen

Spans und Transaktionen geben jeweils unterschiedliche Teile einer Abfrage im System wieder. Sie in einen gemeinsamen Kontext zu bringen, kann jedoch ein recht komplexes Unterfangen sein. Die nächste Abfrage nutzt mehrere geschachtelte Unterabfragen. Sie bildet die Gesamtzahl der Transaktionen in jedem Service ab, der Spans enthält, die langsamer sind als 99 % aller Spans. Mit ihr lassen sich so Bottlenecks im System ausmachen.

FROM Transaction SELECT count(*) WHERE entity.guid IN (
    FROM Span SELECT latest(entity.guid) WHERE duration > (
        FROM Span SELECT percentile(duration, 99)
    ) FACET entity.guid ORDER BY average(duration) LIMIT 100
) FACET appName

Das Muster FROM Event SELECT latest(attribute) FACET attribute ORDER BY average(numAttribute) für eine Unterabfrage kann sich als sehr nützlich erweisen. In diesem konkreten Fall lassen sich mit ihm die 100 guids für Entitäten mit der längsten Dauer abfragen, um sie dann in der übergeordneten Abfrage zu verwenden. Hierbei handelt es sich um die zweite Ebene der Unterabfrage in der vorhergehenden.

So nutzen Sie Unterabfragen optimal

Wie bei so vielem macht auch bei Unterabfragen Übung den Meister. Mit diesen Best Practices gelingt Ihnen der Einstieg:

  • Abfragetest ohne Unterabfrage. Führen Sie die übergeordnete Abfrage mit Testwerten aus, um sie zu validieren, bevor Sie die Unterabfrage einsetzen.
  • Isolierte Tests für Unterabfragen. Führen Sie die Unterabfrage aus und prüfen Sie dann die Ergebnisse, bevor Sie sie in der übergeordneten Abfrage einsetzen.
  • Unterabfragen: Möglichkeiten und Einschränkungen. In der Dokumentation zu NRQL-Unterabfragen gehen wir auch auf ihre Grenzen ein.
  • Zusätzlicher Wirkungskreis mit Data Plus. Data Plus verdreifacht die mögliche Anzahl an Abfragen und verdoppelt die maximal mögliche Abfragedauer. Möglich macht Data Plus zudem die Prüfung von bis zu 1 Billion an Datenpunkten pro 30 Minuten und 100 Milliarden pro Minute (gegenüber 300 Milliarden Datenpunkten pro 30 Minuten und 10 Milliarden pro Minute bei der Standard-Datenoption in New Relic).
  • Ergebnistyp für Unterabfragen im Blick. Der Ergebnistyp bedingt wiederum die Clauses, in denen sich die Unterabfrage nutzen lässt.
    • Gibt die Unterabfrage ein tabellarisches Ergebnis mit vielen Werten aus, ist sie nur als Teil einer IN-Clause nutzbar, so etwa in FACET- oder uniques(...)-Abfragen.
    • In anderen Zusammenhängen, zum Beispiel bei „entspricht“-Abfragen mit (=) oder arithmetischen Varianten (+, - etc.), benötigen FACET- oder columns-Abfragen LIMIT 1.
    • Abfragen auf einen Einzelwert lassen sich überall dort nutzen, wo ein Literal verwendet werden kann, beispielsweise in einer Zahl oder einem Text-String. Es gibt aber auch Grenzfälle, die aktuell nicht unterstützt werden, so etwa bei der Anzahl an Buckets für eine Histogramm-Funktion Ist eine Abfrage nicht nutzbar formuliert, gibt das System für Unterabfragen eine zielführende Fehlermeldung aus.

Unterabfragen machen komplexe, präzise Abfragen über verschiedene Datenquellen und Zeitbereiche hinweg möglich und sind so ein starkes Tool zur Datenanalyse. In diesem Blog-Post haben wir uns auf einige wichtige Use-Case-Beispiele beschränkt – das tatsächliche Potenzial ist aber schier endlos. Schon bald werden Sie sicher ihre eigenen Möglichkeiten ausloten. Viel Spaß dabei!