Sankey-diagram over API-kald: fra endpoints til fejl
Følg API-kald fra endpoint til statusklasse og til årsagen bag hver fejl. Se, hvilke endpoints der giver fejl, og hvorfor, og erstat eksempeltallene med dine egne logs.
Et Sankey-diagram over API-udfald følger kald fra det endpoint, der modtog dem, til succes eller en fejlklasse, og fordeler derefter hver fejlklasse efter årsag. Det peger på det endpoint og den årsag, der er værd at rette først.
Eksemplet har én million kald fordelt på fire endpoints. Heraf lykkes 920 tusinde, 60 tusinde er klientfejl (4xx) og 20 tusinde er serverfejl (5xx). Den sidste kolonne giver årsagen til hver fejl: ugyldigt input, udløbet token, ikke fundet og rate limiting på klientsiden; timeout, fejl i en afhængighed og bug på serversiden.
En fejlrate pr. endpoint er ét enkelt tal. Sankey-diagrammet bevarer ruten: Checkout har den højeste serverfejlrate i eksemplet (7 af 150), og Login den højeste klientfejlrate (22 af 200). Tallene er opdigtede. Brug antal for ét tidsvindue, og angiv, om genforsøg tælles én gang eller hver gang. Den samme tanke for alarmer i stedet for kald er /da/sankey/incident-response.
Sådan læser du dette diagram
- 920 af 1.000 tusinde kald (92 %) lykkes; 6 % er klientfejl og 2 % serverfejl.
- Checkout har den højeste serverfejlrate: 7 af 150 (omkring 5 %).
- Login har den højeste klientfejlrate: 22 af 200 kald (11 %). Udløbne tokens står for 20 af de 60 klientfejl.
- Halvdelen af serverfejlene (10 af 20) er timeouts.
Data bag diagrammet
Opdigtede tal til illustration. Ikke data om nogen rigtig virksomhed, noget team eller system.
| Fra | Til | Mængde (tusind kald) |
|---|---|---|
| Søgning | Succes (2xx) | 370 |
| Søgning | Klientfejl (4xx) | 22 |
| Søgning | Serverfejl (5xx) | 8 |
| Checkout | Succes (2xx) | 135 |
| Checkout | Klientfejl (4xx) | 8 |
| Checkout | Serverfejl (5xx) | 7 |
| Login | Succes (2xx) | 175 |
| Login | Klientfejl (4xx) | 22 |
| Login | Serverfejl (5xx) | 3 |
| Katalog | Succes (2xx) | 240 |
| Katalog | Klientfejl (4xx) | 8 |
| Katalog | Serverfejl (5xx) | 2 |
| Klientfejl (4xx) | Ugyldigt input | 25 |
| Klientfejl (4xx) | Udløbet token | 20 |
| Klientfejl (4xx) | Ikke fundet | 10 |
| Klientfejl (4xx) | Rate limited | 5 |
| Serverfejl (5xx) | Timeout | 10 |
| Serverfejl (5xx) | Fejl i afhængighed | 6 |
| Serverfejl (5xx) | Bug | 4 |
De samme data som CSV
source,target,value
Søgning,Succes (2xx),370
Søgning,Klientfejl (4xx),22
Søgning,Serverfejl (5xx),8
Checkout,Succes (2xx),135
Checkout,Klientfejl (4xx),8
Checkout,Serverfejl (5xx),7
Login,Succes (2xx),175
Login,Klientfejl (4xx),22
Login,Serverfejl (5xx),3
Katalog,Succes (2xx),240
Katalog,Klientfejl (4xx),8
Katalog,Serverfejl (5xx),2
Klientfejl (4xx),Ugyldigt input,25
Klientfejl (4xx),Udløbet token,20
Klientfejl (4xx),Ikke fundet,10
Klientfejl (4xx),Rate limited,5
Serverfejl (5xx),Timeout,10
Serverfejl (5xx),Fejl i afhængighed,6
Serverfejl (5xx),Bug,4Sådan fungerer det
Eksportér et tidsvindue af request-logs
Tag én time, én dag eller én uge med endpoint og statuskode for hvert kald.
Gruppér endpoints og statuskoder
Behold de fire til seks mest brugte endpoints, og gruppér resten som Andet. Gruppér statuskoder i klasser.
Tilføj årsagen til hver fejl
Brug den fejlkode eller fejlmeddelelse, din service returnerer. Gruppér årsagerne i fem til syv labels.
Kontrollér balancen
Hver fejlklasse skal afgive lige så mange kald, som den modtager. Succeser ender i anden kolonne.
Ofte stillede spørgsmål
Skal omdirigeringer (3xx) vises?
Kun hvis de har betydning for dit spørgsmål. Ellers tæl dem som succes, eller udelad dem og skriv det i datanoten.
Kan jeg bruge det til overvågning i realtid?
Nej. Det er et billede af et fast vindue. Et overvågningsværktøj er bedre til live-rater; diagrammet er til at forklare, hvor fejlene kommer fra.
Redigér dette Sankey-diagram over API-kald
Åbn eksemplet som dit eget diagram, og indtast dine antal kald.