Ein Problem untersuchen

Untersuchen heißt, vom Symptom zur Ursache zu gehen, ohne unterwegs zu raten. Der Radar ist für diesen Weg gebaut: Man wählt, was fehlgeschlagen ist, sieht jede Ausführung einzeln, und geht zurück bis zu dem Schritt, der sie ausgelöst hat.

Diese Seite geht diesen Weg in vier Etappen — die API, die Sitzung, das Problem, und der Audit-Eintrag, der erklärt, warum jetzt.

#Eine API, die fehlschlägt

1. Öffnen Sie die App und gehen Sie zu Radar.
2. Klicken Sie im Abschnitt APIs und Skripte auf die Zeile der API — zum Beispiel oportunidades.
3. Es öffnet sich ein Tab mit ihrem Namen, und oben drei Etiketten: der interne Name, 116 Aufrufe und Ø 4ms. Wenn es Fehlschläge gibt, erscheint auch „N Fehlschläge (X%)".

Die Tabelle hat eine Zeile pro Aufruf — niemals gruppiert — mit fünf Spalten:

Spalte	Was sie zeigt
Wann	Der Moment des Aufrufs.
Status	Der zurückgegebene HTTP-Status.
Operation	Die angeforderte Operation, wenn der Aufruf sie identifiziert.
Ergebnis	kein Fehler, oder der Typ des Fehlers, der geplatzt ist.
Zeit	Wie lange er gedauert hat.

Die Leiste Filtern… über der Tabelle reduziert die Liste nach jedem dieser Felder: nur die Fehlschläge, nur die über 500 ms, nur die von heute. Die Paginierung unten sagt, wo Sie sind — 1–50 von 116.

#Das Detail eines Aufrufs

Klicken Sie auf eine Zeile, und unten öffnet sich das Detail-Panel, mit drei Tabs:

Tab	Was er bringt
Allgemein	Wann, Zeit, Status, Herkunft, wer den Aufruf gemacht hat und der Trace, der ihn identifiziert.
Gesendet	Was der Aufruf mitgeführt hat. Bei Zweifeln an Typen zeigt er Feld für Feld das Gesendet und den Erwarteter Typ, mit dem Verdächtigen in Rot.
Antwort	Was zurückkam. Ein Aufruf, der nichts zurückgab, sagt „Es kam nichts zurück."; einer, der nichts mitführte, sagt „Dieser Aufruf hat nichts mitgeführt."

Die Skripte haben ein Zwillings-Panel: eine Zeile pro Ausführung, mit dem Exit-Code, dem Auslöser des Starts und der Konsole — der Ausgabe, die das Skript geschrieben hat. Ein Skript ohne Ausführungen im Zeitraum sagt „Keine Ausführungen aufgezeichnet."

#Die Zeitleiste einer Sitzung

Ein isolierter Aufruf erklärt selten einen Fehler. Die nächste Frage ist immer „was hat die Person gerade gemacht?" — und dafür sind die Sitzungen da.

1. Klappen Sie in Radar den Abschnitt Sitzungen aus.
2. Klicken Sie auf den Besuch, der Sie interessiert — 23:11 · demo.
3. Das Panel öffnet mit dem, der hereinkam, wann, und einer Zusammenfassung: 15 Schritte auf 5 Seiten.

Die Tabelle ist die Zeitleiste des Besuchs, ein Schritt pro Zeile:

Spalte	Was sie zeigt
Name	Der Schritt: eine Seite, ein Bildschirm, ein Ereignis, ein Aufruf einer API, eine Datenlesung.
Status	Ob er gut oder schlecht lief.
Herkunft	Woher der Schritt kam — Seiten, Bildschirme, Aktionen, Daten.
Zeit	Wie lange er gedauert hat.
Wasserfall	Der Balken, der zeigt, wann er innerhalb der Sitzung geschah und wie viel er belegte.

Der Wasserfall ist es, der das Lesen unmittelbar macht: Die Balken richten sich in der Zeit aus, und einen Schritt, der lange dauerte, sieht man, ohne eine einzige Zahl zu lesen. Klicken Sie auf eine Zeile für das Detail — mit Seite, Wann, Zeit und Seit Beginn der Sitzung (+0.0s, +2.4s, …). Ein Schritt, der den Server nicht aufgerufen hat, sagt es: „Dieser Schritt hat den Server nicht aufgerufen."

#Ein Code-Fehler

Die Fehler, die im Code der Ereignisse entstanden sind, erscheinen im Abschnitt Bildschirme, nach Ursache gruppiert: ein Problem pro unterschiedlichem Fehler, mit der Zahl der Vorkommen daneben.

Klicken Sie auf eines, um das Panel des Problems zu öffnen, das alles zusammenführt, was man über es weiß:

Zone	Was sie beantwortet
Code	Der Auszug Ihres Codes, mit der schuldigen Zeile hervorgehoben, und die genaue Position.
Weg bis hierher	Was die Person tat, bevor es platzte — Seite, Bildschirm, Datenlesungen, der letzte Klick.
Spur des Fehlers	Die technische Spur, wenn sie gespeichert wurde.
Ablauf	Der Weg des Fehlers durch die Teile der App.
Im Designer öffnen	Bringt Sie direkt zu dem Ereignis, in dem der Fehler entstand.

Der Button Im Designer öffnen ist das natürliche Ende der Untersuchung: Sie haben die Zeile gefunden, jetzt beheben Sie sie.

Ein Fehler, den die Plattform als Von der Plattform eingestuft hat, zeigt etwas anderes: „Dieser Fehler ist in der Runtime von Keplin entstanden, nicht im Code Ihrer App. Auf Ihrer Seite gibt es nichts zu beheben — es lohnt sich, ihn zu melden." — mit einer Referenz zum Kopieren.

#Die Probleme, in allen Apps

Das Menü Observability → Probleme ist derselbe Stoff, zusammen und mit Status. Jede Zeile ist ein gruppiertes Problem, mit Vorkommen, Betroffene Benutzer, Zuerst gesehen und Zuletzt gesehen.

Eine gesunde Installation hat diese Seite leer — „Kein Problem entspricht diesen Filtern", mit Filter leeren, um die Suche zu weiten. Bevor Sie schließen, dass es keine Probleme gibt, prüfen Sie den Zeitraum oben: Mit gewähltem 1h erscheint ein Fehler von gestern nicht.

Jedes Problem hat drei Status, und sie werden im Panel selbst geändert:

Aktion	Was sie tut
Beheben	Markiert es als erledigt — „Problem als behoben markiert." Passiert es erneut, öffnet es sich von selbst wieder.
Ignorieren	Nimmt es aus dem Weg, ohne es zu beheben — „Problem ignoriert." Für das Rauschen, das man kennt.
Wieder öffnen	Gibt es an offen zurück — „Problem wieder geöffnet."

Innerhalb eines Problems zeichnet die Kette des Problems den Weg: den Kontext im Browser, die korrelierten Ausführungen, den Fehler und die beobachtete Auswirkung. Wenn es keinen Weg gibt, die Teile zu verbinden, sagt sie es, statt zu erfinden — „Die gestrichelten Verbindungen zeigen nur bestätigten Kontext, keine abgeleitete kausale Beziehung."

#Die Ereignisse, eines nach dem anderen

Observability → Ereignisse ist die rohe Liste: eine Zeile pro Ausführung von API, Skript oder System, einschließlich derer, die gut liefen.

Spalten: Wann, Typ, App, Was, Dauer und Ergebnis. Die Filter oben schneiden nach App, Typ, Status, Schweregrad und Zeitraum; Filter leeren setzt alles zurück.

Klicken Sie auf eine Zeile, und das Detail öffnet daneben, mit Zusammenfassung und Daten — und Vollständige Seite öffnen, wenn Sie mehr Platz brauchen. Die Fehlermeldungen erscheinen in der Originalsprache des Servers, mit Absicht: Sie zu übersetzen würde sie von dem Text entfernen, den man in der Dokumentation sucht.

#Und warum jetzt? Das Audit

Ein Fehler, der heute begann, hat fast immer eine Änderung dahinter. Observability → Audit bewahrt die administrativen und Konfigurationsänderungen auf — erstellen, ändern, löschen, ausführen, importieren, exportieren, widerrufen, Passwort zurücksetzen, Rolle ändern — mit dem, der sie machte, in welcher App und wann.

Klicken Sie auf eine Zeile, und das Detail zeigt das Vorher und das Nachher der Änderung. Es ist die direkte Antwort auf die Frage, die die meisten Untersuchungen abschließt: „Was hat sich gestern Nachmittag geändert?"

#Der Weg, zusammengefasst

1. Übersicht — welche App brennt.
2. Radar der App — welche API, welches Skript oder welcher Bildschirm.
3. Sein Panel — welcher Aufruf, mit welchen Daten, in welchem Moment.
4. Die Sitzung — was die Person vorher tat.
5. Das Problem — die Codezeile und der Button Im Designer öffnen.
6. Das Audit — was sich geändert hat, damit das anfing.

#Warum sehe ich nicht…?

• …das Detail eines Aufrufs? Keine Zeile ist ausgewählt. Die Tabelle sagt „Wählen Sie eine Zeile, um das Detail zu sehen."
• …die Vorkommen eines alten Problems? Sie können von der Rotation der Einträge entfernt worden sein — das Panel warnt, wenn das passiert.
• …den Weg bis hierher ausgefüllt? Nicht alle Vorkommen bringen den Weg mit; wenn nicht, sagt das Panel „Für dieses Vorkommen wurde kein Weg aufgezeichnet.", statt erfundene Schritte zu zeigen.
• …den Button Im Designer öffnen? Er erscheint nur bei Fehlern mit Ursprung im Code der App. Die Fehler der Plattform haben nichts zu öffnen.