API-Anfrageergebnisse im Sankey-Diagramm: Endpunkte bis Fehler
Verfolgen Sie API-Anfragen vom Endpunkt über die Statusklasse bis zur Ursache jedes Fehlers. Sehen Sie, welche Endpunkte scheitern und warum, und ersetzen Sie die Beispielwerte durch Ihre Logs.
Ein Sankey-Diagramm der API-Ergebnisse folgt Anfragen vom Endpunkt, der sie erhielt, zu Erfolg oder Fehlerklasse und teilt jede Fehlerklasse nach Ursache. Es zeigt auf den Endpunkt und die Ursache, die zuerst behoben werden sollten.
Das Beispiel hat eine Million Anfragen über vier Endpunkte. Davon sind 920 Tausend erfolgreich, 60 Tausend Client-Fehler (4xx) und 20 Tausend Server-Fehler (5xx). Die letzte Spalte nennt die Ursache jedes Fehlers: ungültige Eingabe, abgelaufenes Token, nicht gefunden und Ratenbegrenzung auf der Client-Seite; Timeout, Ausfall einer Abhängigkeit und Bug auf der Server-Seite.
Eine Fehlerrate pro Endpunkt ist eine einzelne Zahl. Das Sankey-Diagramm behält den Weg: Checkout hat im Beispiel die höchste Server-Fehlerrate (7 von 150) und Login die höchste Client-Fehlerrate (22 von 200). Die Zahlen sind erfunden. Verwenden Sie Zählwerte für ein Zeitfenster und geben Sie an, ob Wiederholungen einmal oder jedes Mal gezählt werden. Dieselbe Idee für Alarme statt Anfragen zeigt /de/sankey/incident-response.
So liest man dieses Diagramm
- 920 von 1.000 Tausend Anfragen (92 %) sind erfolgreich; 6 % sind Client-Fehler und 2 % Server-Fehler.
- Checkout hat die höchste Server-Fehlerrate: 7 von 150 (etwa 5 %).
- Login hat die höchste Client-Fehlerrate: 22 von 200 Anfragen (11 %). Abgelaufene Tokens verursachen 20 der 60 Client-Fehler.
- Die Hälfte der Server-Fehler (10 von 20) sind Timeouts.
Die Daten dahinter
Erfundene Zahlen zur Veranschaulichung. Keine Daten eines realen Unternehmens, Teams oder Systems.
| Von | Nach | Menge (Tsd. Anfragen) |
|---|---|---|
| Suche | Erfolg (2xx) | 370 |
| Suche | Client-Fehler (4xx) | 22 |
| Suche | Server-Fehler (5xx) | 8 |
| Checkout | Erfolg (2xx) | 135 |
| Checkout | Client-Fehler (4xx) | 8 |
| Checkout | Server-Fehler (5xx) | 7 |
| Login | Erfolg (2xx) | 175 |
| Login | Client-Fehler (4xx) | 22 |
| Login | Server-Fehler (5xx) | 3 |
| Katalog | Erfolg (2xx) | 240 |
| Katalog | Client-Fehler (4xx) | 8 |
| Katalog | Server-Fehler (5xx) | 2 |
| Client-Fehler (4xx) | Ungültige Eingabe | 25 |
| Client-Fehler (4xx) | Abgelaufenes Token | 20 |
| Client-Fehler (4xx) | Nicht gefunden | 10 |
| Client-Fehler (4xx) | Ratenbegrenzt | 5 |
| Server-Fehler (5xx) | Timeout | 10 |
| Server-Fehler (5xx) | Ausfall einer Abhängigkeit | 6 |
| Server-Fehler (5xx) | Bug | 4 |
Dieselben Daten als CSV
source,target,value
Suche,Erfolg (2xx),370
Suche,Client-Fehler (4xx),22
Suche,Server-Fehler (5xx),8
Checkout,Erfolg (2xx),135
Checkout,Client-Fehler (4xx),8
Checkout,Server-Fehler (5xx),7
Login,Erfolg (2xx),175
Login,Client-Fehler (4xx),22
Login,Server-Fehler (5xx),3
Katalog,Erfolg (2xx),240
Katalog,Client-Fehler (4xx),8
Katalog,Server-Fehler (5xx),2
Client-Fehler (4xx),Ungültige Eingabe,25
Client-Fehler (4xx),Abgelaufenes Token,20
Client-Fehler (4xx),Nicht gefunden,10
Client-Fehler (4xx),Ratenbegrenzt,5
Server-Fehler (5xx),Timeout,10
Server-Fehler (5xx),Ausfall einer Abhängigkeit,6
Server-Fehler (5xx),Bug,4So funktioniert es
Ein Fenster von Request-Logs exportieren
Nehmen Sie eine Stunde, einen Tag oder eine Woche, mit Endpunkt und Statuscode je Anfrage.
Endpunkte und Statuscodes gruppieren
Behalten Sie die vier bis sechs meistgenutzten Endpunkte und fassen Sie den Rest als „Sonstige“ zusammen. Gruppieren Sie Statuscodes in Klassen.
Die Ursache jedes Fehlers ergänzen
Nutzen Sie den Fehlercode oder die Meldung Ihres Dienstes. Fassen Sie Ursachen in fünf bis sieben Labels zusammen.
Die Bilanz prüfen
Jede Fehlerklasse muss so viele Anfragen abgeben, wie hineinflossen. Erfolge enden in der zweiten Spalte.
Häufig gestellte Fragen
Sollen Weiterleitungen (3xx) gezeigt werden?
Nur wenn sie für Ihre Frage zählen. Sonst rechnen Sie sie zum Erfolg oder lassen sie weg und sagen das in der Datenanmerkung.
Kann ich das für Echtzeit-Monitoring nutzen?
Nein. Es ist ein Bild eines festen Zeitfensters. Für Live-Raten ist ein Monitoring-Tool besser; das Diagramm dient dazu, zu erklären, woher Fehler kommen.
Dieses API-Sankey bearbeiten
Öffnen Sie das Beispiel als eigenes Diagramm und tragen Sie Ihre Anfragezahlen ein.