Zur Definition, Erfassung und Darstellung von Fehlern werden in den Application-Performance-Monitoring(APM)-Services von New Relic und OpenTelemetry jeweils unterschiedliche Methoden verwendet. Kund:innen, die neu bei OpenTelemetry sind, fällt wahrscheinlich auf, dass die Fehlerquotendiagramme für denselben Service jeweils unterschiedliche Werte auf den APM- und OpenTelemetry-Übersichtsseiten anzeigen. In diesem Blogpost wird erläutert, warum das so ist.
Was ist ein Fehler?
Eigentlich eine simple Frage. Eine mögliche Antwort wäre: Jede Transaktion, die eine unbehandelte Ausnahme aufweist, zählt als Fehler.
Fehlerquote bezieht sich auf den Prozentsatz der Transaktionen, die in einem bestimmten Zeitfenster zu Fehlern führen. Wenn Ihre Anwendung beispielsweise in einem bestimmten Zeitraum 1000 Transaktionen verarbeitet und 50 davon nicht behandelte Ausnahmen aufweisen, liegt die Fehlerquote bei 50 ‰ oder 5 %. Die Fehler selbst werden allerdings von OpenTelemetry anders definiert und interpretiert, und daraus ergeben sich auch Unterschiede bei der Fehlerquote. Grund hierfür ist, dass OpenTelemetry das Konzept der Transaktionen nicht verwendet, ebenso wenig wie die zusätzliche Logik, mit der unsere Agents Fehler erfassen und zählen.
Sehen wir uns als Erstes an, wie New Relic Fehler für unsere APM Agents handhabt. Das vergleichen wir dann mit OpenTelemetry.
New Relic APM Agents
New Relic definiert eine Transaktion als eine logische Arbeitseinheit in einer Software-Anwendung. Genauer gesagt besteht diese Arbeitseinheit aus den relevanten Funktions- und Methodenaufrufen. Im Zusammenhang mit APM bezieht sich der Begriff oft auf eine Webtransaktion, die mit dem Empfang einer Webanfrage durch die Anwendung beginnt und mit dem Versand der Antwort endet.
Mehr zu Transaktionsarten und -unterarten erfahren Sie hier.
Transaktionsfehlerlogik
Pro Transaktion zeichnen wir nur einen Fehler auf. Selbst wenn eine Arbeitseinheit mehrere Fehler aufweist, werden diese für die Fehlerquote nur als ein Fehler pro Transaktion gezählt, und zwar in absteigender Reihenfolge nach den folgenden Fehlertypen priorisiert:
- NoticeError API
- Durch Instrumentierung beobachtete Ausnahme
- Webtransaktion mit einem Statuscode >= 400
Sobald ein Fehler definiert wurde, erfasst das Event TransactionError Details wie den Ausnahmetyp und Stack-Trace. New Relic APM unterstützt zudem das Konzept „ignorierter“ und „erwarteter“ Fehler über die Agent-Konfiguration.
Beispiel für New Relic
Diese Transaktion umfasst vier instrumentierte Methoden. Sowohl Methode B als auch Methode D weisen Fehler auf, allerdings wird in dieser Instanz nur der erste (nach Vorrang) Fehler mit dazugehörigen Details aufgezeichnet.
Wird ein unerwarteter Fehler aufgezeichnet, wird die Fehleranzahl entsprechend erhöht und als Metrik vom New Relic APM Agent aufgezeichnet (apm.service.error.count). Die Fehlerquote auf der APM-Übersichtsseite wird anhand dieser Metrik berechnet, wie im nachstehenden Screenshot gezeigt. Die Berechnung und Darstellung der Fehlerquote berücksichtigt nicht das TransactionError-Event, da es sich lediglich um eine Stichprobe handelt und das Dataset somit begrenzt wäre.
Beispiel für eine NRQL-Abfrage:
SELECT sum(apm.service.error.count['count']) / count(apm.service.transaction.duration) AS 'Web errors' FROM Metric WHERE (entity.guid = 'foo') AND (transactionType = 'Web') LIMIT MAX SINCE 30 MINUTES AGO TIMESERIESWeitere Informationen zum Fehlermanagement bei New Relic Agents finden Sie in unserer Dokumentation.
OpenTelemetry
Fehler aus erfassten OpenTelemetry-Daten werden auf zwei Arten definiert, wodurch verschiedene Teile unserer UIs verändert werden:
- OpenTelemetry-Metriken, die für das Fehlerquotendiagramm auf der Übersichtsseite für OpenTelemetry APM genutzt werden
- Aus Spans definierte Transaktionen, die für die Errors Inbox verwendet werden
Fehler aus Metriken (OpenTelemetry-APM-Übersicht)
Auf der New Relic OpenTelemetry-Übersichtsseite können Sie zwischen Metriken oder Spans wechseln.
Metriken: Ein wesentlicher Unterschied zwischen APM und OpenTelemetry ist die Tatsache, dass die HTTP Metrics-Spezifikation von OpenTelemetry keine Fehlerzahlmetrik aufweist. Für OpenTelemetry APM in New Relic bezieht sich das Fehlerquotendiagramm auf die Zeitspannenmetrik http.server.request.duration oder rpc.server.duration und klassifiziert Instanzen mit Fehlercode >=500 als die Fehlerquote. Deshalb ist die Fehlerquote von Metriken auf HTTP-Aufrufe begrenzt.
Beispiel für eine NRQL-Abfrage:
SELECT filter(count(http.server.request.duration), WHERE numeric(http.status_code) >= 500 OR numeric(http.response.status_code) >= 500)/count(http.server.request.duration) as 'Error rate for all errors' FROM Metric WHERE (entity.guid = 'foo') AND (http.server.request.duration IS NOT NULL OR http.server.request.duration IS NOT NULL) SINCE 30 minutes ago TIMESERIESSpans: Wenn das Fehlerquotendiagramm aus Spans abgeleitet wird, zählen alle OpenTelemetry-Spans mit SpanKind-Typ Server oder Consumer und dem Statuscode ERROR als Fehler. Die aus Spans abgeleitete Fehlerquote ist daher protokollunabhängig.
Beispiel für eine NRQL-Abfrage:
SELECT filter(count(*), WHERE otel.status_code = 'ERROR')/count(*) as 'Error rate for all errors' FROM Span WHERE (entity.guid = 'foo') AND ((span.kind LIKE 'server' OR span.kind LIKE 'consumer' OR kind LIKE 'server' OR kind LIKE 'consumer')) SINCE 30 minutes ago TIMESERIESFehler aus Spans (Errors Inbox)
OpenTelemetry kennt das Konzept einer Transaktion nicht, verfügt aber über Spans – die wiederum Vorgänge innerhalb einer Transaktion darstellen. Zur richtigen Zuordnung von Trace-Daten zum New Relic Transaktionskonzept nutzen wir SpanKind. Der SpanKind-Typ Server oder Consumer wird zur Ermittlung des Einstiegspunkts eines Prozesses genutzt. Anders gesagt, sind dies Spans, die entweder Root Spans oder Child Spans eines Remote-Prozesses sind.
Nicht nur Transaktionen werden in OpenTelemetry nicht separat definiert, es gibt auch keine eigene Fehlerquotenmetrik.
Zur Anpassung an New Relic werden OpenTelemetry-Transaktionen durch einen Span-Typ Server definiert, wobei die Child Spans die untergeordneten Vorgänge der Transaktion ausmachen.
Bei dieser Transaktionsdefinition gilt die Transaktion nur dann als Fehler, wenn der Root Span A vom Typ Server den Statuscode ERROR aufweist. Selbst wenn andere Child Spans den Statuscode ERROR haben, ist dies nur dann relevant, wenn der Root Span ebenfalls den Statuscode ERROR aufweist. Weist der Root Span nicht den Statuscode ERROR auf, wird die Transaktion nicht auf die Fehlerquote angerechnet.
Beispiel für OpenTelemetry
In diesem Beispiel werden die Services als Kästchen und die Spans als Kreise dargestellt. Service 1 ruft Service 2 auf, und Service 2 ruft Service 3 auf.
Innerhalb von Service 2 gibt es mehrere instrumentierte Methoden, die zur Erfassung mehrerer Spans führen. Methode A ist vom Typ Server (oder ein Einstiegspunkt für diesen Service) und wird verwendet, um das Konzept einer Transaktion für die APM-UI zu definieren. Innerhalb dieser Abstraktion gibt es mehrere Spans, die den Statuscode ERROR haben.
Da der Root Span einen Fehler aufweist, gilt die Transaktion als Fehler und wird in der Errors Inbox angezeigt.
Fazit
Die Fehlerquoten in New Relic und OpenTelemetry lassen sich nicht direkt vergleichen, da die Modelle grundlegend verschieden sind. Wenn Sie zwischen Instrumentierungsmethoden wechseln, müssen Sie jeweils die Fehler-Baselines Ihres Services wieder festlegen und für Ihre Alert-Bedingungen, Service Level Objectives und Dashboards nutzen.
Nächste Schritte
Wenn Sie New Relic gern zum ersten Mal ausprobieren möchten, richten Sie sich einfach ein kostenloses Konto ein.
Um mehr über die proaktive Erkennung und Triage von Fehlern zu erfahren, sehen Sie sich New Relic Errors Inbox an.
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.
