Fehlerpriorisierung und -behebung mit Speed

Software-Entwicklung hat schon per se auch für die erfahrensten Developer ihre Unwägbarkeiten. Noch mehr gilt dies aber in punkto Analyse und Priorisierung von Fehlern. Denn bei ihrer Behebung geht es um wichtige Sekunden, die bestimmen können, ob Uptime und Stabilität für Kund:innen merkbar leiden und potenziell auch Umsatzverluste nach sich ziehen. 

Damit die zugehörigen Workflows dynamischer werden, braucht es umfassenden Kontext in einer kompakten UX, mit der sich kritische Fehler ebenso punktgenau priorisieren wie beheben lassen. Genau das bietet New Relic im Rahmen der aktuellen Updates für Errors Inbox: Zielführende Kontextdaten liefern die nötigen Insights, um Fehler mit Auswirkungen auf die Kunden-UX rasch auszumachen und so die Lösungszeit deutlich zu verkürzen.

Fehlerpriorisierung und Alerting nach UX-Auswirkung

Ab sofort lassen sich Fehlergruppen in Errors Inbox nach Schweregrad kategorisieren. So erhalten Sie direkt Aufschluss über die Anzahl der von einer bestimmten Fehlergruppe betroffenen Benutzer:innen. Auf Grundlage dieser Metric können Sie zudem Alerts einrichten und so gezielt genau die Fehler angehen, die Ihrer größten Aufmerksamkeit bedürfen.

Näheres dazu, wie Sie Alerts basierend auf der Anzahl betroffener Benutzer:innen einrichten, erfahren Sie in diesem Tutorial.

Schneller zur Fehlerursache dank Einsicht in damit verbundene Traces 

Hinter modernen Anwendungen steht ein komplexes Geflecht aus verschiedensten Komponenten und Services. Kommt es darin zu einem Problem, gestaltet sich die Ursachenermittlung entsprechend schwierig. Dies umso mehr, wenn sich nicht klar nachvollziehen lässt, wie verschiedene Services innerhalb eines Systems miteinander interagieren. Denn dann ist entweder mühsames Entziffern von Fehlermeldungen angesagt, um näher an die Ursache für einen Ausfall zu kommen, oder ineffizientes Hin- und Herwechseln zwischen diversen Tools, um die einzelnen Puzzlestücke zusammenzufügen, aus denen ein Abfall der Anwendungs-Performance resultiert hat.

Errors Inbox adressiert all dies nun mit einer Direktansicht für Distributed Tracing. So erhalten Sie wichtige Insights und können die Fehleranalyse komplett zentral angehen.

Hierzu wählen Sie einfach einen Fehler aus. In der entsprechenden Ansicht erhalten Sie sämtliche damit verbundenen Traces sowie eine Gesamtübersicht der Anfrage einschließlich Dauer, Span-Anzahl und aufgetretenen Fehlern.

Noch detaillierteren Kontext können Sie unter Explore einsehen.

Neben umfassenden Trace-Details zur Anfrage liefert diese granulare Ansicht auch eine visuelle Darstellung sämtlicher erfasster Spans, über die Sie schnell feststellen können, an welchen Punkten etwas im Argen liegt und umso rascher mit adäquaten Maßnahmen gegensteuern. 

Kontextbezogene Zusammenarbeit mit Slack – bis zur Entität

Sicher ist Ihnen die New Relic Integration mit Slack bereits bekannt. Diese haben wir nun dahingehend erweitert, dass Slack Benachrichtigungen bis auf Ebene der Entität unterstützt werden. Für Ihr Team wird dabei noch umfassendere Zusammenarbeit möglich. 

Denn dadurch erhalten Sie Benachrichtigungen nun spezifisch für Ihre service- oder anwendungsbezogene Inbox, können so im Kontext genau der Projekte zusammenarbeiten, deren Entwicklung Sie und Ihr Team jeweils verantworten. 

Näheres zur Anbindung von Errors Inbox an Slack finden Sie in diesem Video:

Außerdem haben wir die einzelnen Schritte im Folgenden für Sie zusammengefasst:

1. Sofern noch nicht geschehen, müssen Sie zunächst die New Relic App in Ihrem Slack Workspace installieren.
2. Öffnen Sie eine Errors Inbox in New Relic und rufen Sie die Benachrichtigungseinstellungen über das Glockensymbol oben rechts im Bildschirm auf.
3. Aktivieren Sie Slack, sofern nötig, über die entsprechende Schaltfläche.
4. Sofern keine Workspaces verfügbar sind, aktivieren Sie Slack über die „+“-Schaltfläche.
5. Im Anschluss an die Authentifizierung können Sie einen Workspace sowie einen Channel auswählen, an den Benachrichtigungen übermittelt werden sollen.
6. Vergewissern Sie sich über Test, dass Benachrichtigungen an den richtigen Channel gesendet werden.

Erste Amtshandlung: Alert-Einrichtung basierend auf betroffenen Benutzer:innen

Das volle Potenzial dieser Funktionalität erschließt sich erst, wenn Sie Daten zu UX-Auswirkungen an New Relic übermitteln. Ist das erledigt, geht es an die Alert-Konfiguration, für die es Folgendes zu bestimmen gilt:

• Die Entitäten, auf die Fehler zurückgehen, für die Sie Monitoring und Alerting einrichten möchten
• Das für Ihren Use Case zielführendste Alert-Signal
• Den Threshold-Wert, der direkten Value für Sie liefert

Nachfolgend ein kurzes Tutorial, das die drei wesentlichen Schritte hierfür aufzeigt:

1. entity.guid für Alerting-Service bestimmen

Ganz grundsätzlich ist die Einrichtung von Alerts für jeden beliebigen NRQL-String möglich. In diesem Beispiel konzentrieren wir uns jedoch auf Entitäten, auf die Fehler mit Auswirkungen auf die Kunden-UX zurückgehen. Handelt es sich bei der jeweiligen Entität um einen APM-Service, wählen Sie in der Navigationsleiste APM & services und anschließend den Service aus, für den Sie Alerting einrichten möchten. Rufen Sie die dem Service zugehörige entity.guid über See metadata and manage tags auf, wie im nachfolgenden Screenshot gezeigt:

Kopieren Sie nun die entity.guid, wie im nachfolgenden Beispiel gezeigt:

Entitäten bestehen für alle Quellen und Workloads, auf die Fehler zurückgehen, sind jedoch nicht auf diese beschränkt.

Worum genau es sich bei einer Entität handelt, können Sie in diesem Artikel unserer Dokumentation nachlesen. Wie Sie eine finden, erfahren Sie hier.

2. Abfrage erstellen und Anzahl betroffener Benutzer:innen abrufen

Zur Ausgabe der betroffenen Benutzer:innen via NRQL-Abfrage müssen Sie zunächst die Services bestimmen, für die Sie Alerting einrichten möchten, und die ihnen zugehörigen entity.guids abrufen.

Rufen Sie im Anschluss an die Bestimmung der entity.guids den Query Builder auf und fügen Sie den folgenden NRQL-String ein: 

Ersetzen Sie entity.guid durch die GUIDs der Services, für die Sie Alerting einrichten möchten.

Anhand dieser Abfrage wird die Anzahl der eindeutigen Benutzer:innen abgerufen, die von der Fehlergruppe betroffen sind, die auf die von Ihnen über die entity.guids bestimmten Services zurückgehen. Nun gilt es, einen Alert zu definieren, der bei Überschreiten eines Threshold-Werts für die Anzahl der eindeutigen Benutzer:innen ausgelöst wird, die von einem Fehler betroffen sind.

Dabei lassen sich die zugehörigen Daten zudem im Query Builder visualisieren. Dies ermöglicht eine noch präzisere Abstimmung Ihres Abfrage-Strings.

Nach Abruf des Strings, der das Signal für Ihren Alert erzeugt, wählen Sie Option Create alert. Im nun aufgerufenen Fenster können Sie Ihre NRQL Alert-Bedingung konfigurieren.

3. NRQL-Alert auf Basis der Metric für betroffene Benutzer:innen einrichten

Zur Alert-Einrichtung auf Grundlage Ihrer instrumentierten Services gilt es, eine Alert-Bedingung für NRQL zu definieren. Dies setzen Sie wie folgt um.

Im Fenster Edit an alert condition können Sie die Tresholds definieren, die die Bedingung auslösen. Werden diese überschritten, wird dies nun in der UI angezeigt, sodass Sie den Threshold-Wert optimal nachjustieren können. Welcher Wert dabei ideal ist, hängt ganz vom jeweiligen Use Case ab. Einen guten Ausgangspunkt hierfür bildet jedoch die Kombination aus kleinstem Wert und Dauer der Überschreitung, bei der noch kein Alert ausgelöst wird.

Ebenfalls können Sie das Zeitfenster zur Aggregierung anpassen und so noch punktgenaueres Alerting bei weniger Rauschen erzielen:

Ist das Fenster zu gering bemessen, könnte ein niedriger Threshold für False Positives in Folge geringfügiger Fehler sorgen. Ein zu hoch angesetzter Threshold hingegen könnte in einer per se zwar moderaten, doch gleichermaßen konstant vorhandenen Gruppe betroffener Benutzer:innen resultieren. Mehr zum Zeitfenster zur Datenaggregation lesen Sie in der zugehörigen Dokumentation.

Nun können Sie Ihre Einstellungen speichern. Scrollen Sie nach unten oder blenden Sie die Bereiche zur Alert-Konfiguration aus und wählen Sie Save condition.

Et voilá – damit ist Ihre Alert-Policy nun erstellt und ihre Aktivierung anhand der Standardeinstellungen erfolgt. Näheres zu Policies finden Sie in der zugehörigen Dokumentation. 

Hinweis: Im vorliegenden Beispiel wurde der verwendete NRQL-String nach Fehlergruppe facettiert. Dies bedeutet, dass ein Alert ausgelöst wird, wenn eine Fehlergruppe den Threshold-Wert für die festgelegte Dauer übersteigt. Es wird also die Gesamtzahl der Benutzer:innen gemessen, die von den einzelnen Fehlergruppen betroffen sind. Für Ihren spezifischen Use Case eignet es sich womöglich besser, die Gesamtanzahl aller betroffenen Benutzer:innen zu erfassen. Hierzu müssen Sie nur die FACET-Clause entfernen. Die entsprechende Abfrage sieht dann wie folgt aus:

Außerdem gilt: Sie können innerhalb einer Alert-Bedingung auch Entitäten unterschiedlichen Typs verwenden.