Een probleem onderzoeken

Onderzoeken is van het symptoom naar de oorzaak gaan zonder onderweg te gokken. De Radar is voor die route ontworpen: u kiest wat er mislukt is, u bekijkt elke uitvoering stuk voor stuk, en u volgt de weg terug tot aan de stap die het veroorzaakt heeft.

Deze pagina loopt die weg in vier etappes af — de API, de sessie, het probleem, en de auditregistratie die uitlegt waarom nu.

#Een API die mislukt

1. Open de app en ga naar Radar.
2. Klik in de sectie API's en scripts op de regel van de API — bijvoorbeeld oportunidades.
3. Er opent een tabblad met haar naam, en bovenaan drie labels: de interne naam, 116 aanroepen en gemiddeld 4 ms. Wanneer er mislukkingen zijn, verschijnt ook "N mislukkingen (X%)".

De tabel heeft één regel per aanroep — nooit gegroepeerd — met vijf kolommen:

Kolom	Wat die toont
Wanneer	Het moment van de aanroep.
Status	De teruggegeven HTTP-status.
Bewerking	De gevraagde bewerking, wanneer de aanroep haar aanduidt.
Resultaat	geen fout, of het soort fout dat is opgetreden.
Tijd	Hoe lang die duurde.

De balk Filteren… boven de tabel beperkt de lijst op elk van deze velden: alleen de mislukkingen, alleen die boven de 500 ms, alleen die van vandaag. De paginering onderaan zegt waar u bent — 1–50 van 116.

#Het detail van een aanroep

Klik op een regel en het detailpaneel opent onderaan, met drie tabbladen:

Tabblad	Wat dat meebrengt
Algemeen	Wanneer, Tijd, Status, Oorsprong, Wie de aanroep deed en de Trace die haar aanduidt.
Verstuurd	Wat de aanroep meenam. Bij twijfel over types toont hij veld voor veld het Verstuurd en het Verwacht type, met de verdachte in het rood.
Antwoord	Wat er terugkwam. Een aanroep die niets teruggaf, zegt "Er kwam niets terug."; een die niets meenam, zegt "Deze aanroep nam niets mee."

De scripts hebben een tweelingpaneel: één regel per uitvoering, met de Afsluitcode, de Oorsprong van de trigger en de Console — de uitvoer die het script geschreven heeft. Een script zonder uitvoeringen in de periode zegt "Geen uitvoeringen vastgelegd."

#De tijdlijn van een sessie

Een losse aanroep verklaart zelden een fout. De volgende vraag is altijd "wat was die persoon aan het doen?" — en daar dienen de sessies voor.

1. Klap in Radar de sectie Sessies uit.
2. Klik op het bezoek dat u interesseert — 23:11 · demo.
3. Het paneel opent met wie binnenkwam, wanneer, en een samenvatting: 15 stappen op 5 pagina's.

De tabel is de tijdlijn van het bezoek, één stap per regel:

Kolom	Wat die toont
Naam	De stap: een pagina, een scherm, een gebeurtenis, een aanroep van een API, een leesactie op gegevens.
Status	Of die goed of slecht ging.
Oorsprong	Waar de stap vandaan kwam — Pagina's, Schermen, Acties, Gegevens.
Tijd	Hoe lang die duurde.
Waterval	De balk die laat zien wanneer die binnen de sessie gebeurde en hoeveel die in beslag nam.

De waterval is wat het lezen onmiddellijk maakt: de balken staan op de tijd uitgelijnd, en een stap die lang duurde, ziet u zonder ook maar één getal te lezen. Klik op een regel voor het detail — met Pagina, Wanneer, Tijd en Sinds het begin van de sessie (+0.0s, +2.4s, …). Een stap die de server niet heeft aangeroepen, zegt het: "Deze stap heeft de server niet aangeroepen."

#Een fout in de code

De fouten die in de code van de gebeurtenissen zijn ontstaan, verschijnen in de sectie Schermen, gegroepeerd op oorzaak: één probleem per verschillende fout, met het aantal voorvallen ernaast.

Klik op een probleem om het paneel ervan te openen, dat alles bijeenbrengt wat erover bekend is:

Zone	Wat die beantwoordt
Code	Het fragment van uw code, met de schuldige regel uitgelicht, en de exacte Positie.
Pad tot hier	Wat de persoon deed voordat het klapte — pagina, scherm, leesacties op gegevens, de laatste klik.
Spoor van de fout	Het technische spoor, wanneer dat bewaard is.
Flow	De route van de fout langs de onderdelen van de app.
In de designer openen	Brengt u rechtstreeks naar de gebeurtenis waar de fout is ontstaan.

De knop In de designer openen is het natuurlijke einde van het onderzoek: u hebt de regel gevonden, nu gaat u haar verhelpen.

Een fout die het platform als Van het platform heeft geclassificeerd, toont iets anders: "Deze fout is ontstaan in de runtime van Keplin, niet in de code van uw app. Er valt aan uw kant niets te verhelpen — het is de moeite waard om hem te melden." — met een Referentie om te kopiëren.

#De problemen, in alle apps

Het menu Observability → Problemen is dezelfde stof, bijeengebracht en met een status. Elke regel is een gegroepeerd probleem, met Voorvallen, Getroffen gebruikers, Voor het eerst gezien en Voor het laatst gezien.

Een gezonde installatie heeft deze pagina leeg — "Geen enkel probleem komt met deze filters overeen", met Filters wissen om het zoeken te verruimen. Controleer, voordat u concludeert dat er geen problemen zijn, de periode bovenaan: met 1u gekozen verschijnt een fout van gisteren niet.

Elk probleem heeft drie statussen, en die wijzigt u in het paneel zelf:

Actie	Wat die doet
Oplossen	Markeert het als afgehandeld — "Probleem als opgelost gemarkeerd." Gebeurt het opnieuw, dan gaat het vanzelf weer open.
Negeren	Haalt het uit de weg zonder het op te lossen — "Probleem genegeerd." Voor de ruis die u kent.
Heropenen	Zet het terug op open — "Probleem heropend."

Binnen een probleem tekent de Keten van het probleem de route: de context in de browser, de gecorreleerde uitvoeringen, de fout en de waargenomen impact. Wanneer de onderdelen niet aan elkaar te knopen zijn, zegt hij dat in plaats van iets te verzinnen — "De gestippelde verbindingen staan alleen voor bevestigde context, niet voor een afgeleid oorzakelijk verband."

#De gebeurtenissen, één voor één

Observability → Gebeurtenissen is de rauwe lijst: één regel per uitvoering van een API, een script of het systeem, inclusief die welke goed gingen.

Kolommen: Wanneer, Soort, App, Wat, Duur en Resultaat. De filters bovenaan snijden op App, Soort, Status, Ernst en periode; Filters wissen zet alles terug.

Klik op een regel en het detail opent ernaast, met Overzicht en Gegevens — en De volledige pagina openen wanneer u meer ruimte nodig hebt. De foutmeldingen verschijnen in de oorspronkelijke taal van de server, met opzet: ze vertalen zou ze verwijderen van de tekst die men in de documentatie opzoekt.

#En waarom nu? De audit

Een fout die vandaag begonnen is, heeft bijna altijd een wijziging achter zich. Observability → Audit bewaart de wijzigingen in beheer en configuratie — aanmaken, wijzigen, verwijderen, uitvoeren, importeren, exporteren, intrekken, wachtwoord herstellen, rol wijzigen — met wie ze deed, in welke app en wanneer.

Klik op een regel en het detail toont het Voor en het Na van de wijziging. Dat is het rechtstreekse antwoord op de vraag die de meeste onderzoeken afsluit: "wat is er gisterenmiddag veranderd?"

#De route, samengevat

1. Overzicht — welke app in brand staat.
2. Radar van de app — welke API, welk script of welk scherm.
3. Het paneel ervan — welke aanroep, met welke gegevens, op welk moment.
4. De sessie — wat de persoon daarvoor deed.
5. Het probleem — de regel code en de knop In de designer openen.
6. De Audit — wat er veranderd is om dit te laten beginnen.

#Waarom zie ik niet…?

• …het detail van een aanroep? Er is geen regel geselecteerd. De tabel zegt "Kies een rij om het detail te zien."
• …de voorvallen van een oud probleem? Die kunnen door de rotatie van de registraties zijn weggehaald — het paneel waarschuwt wanneer dat het geval is.
• …het Pad tot hier ingevuld? Niet alle voorvallen brengen de route mee; wanneer ze dat niet doen, zegt het paneel "Geen pad vastgelegd voor dit voorval." in plaats van verzonnen stappen te tonen.
• …de knop In de designer openen? Die verschijnt alleen bij fouten die uit de code van de app komen. De fouten van het platform hebben niets om te openen.