Codesphere Request Browser
Der Request Browser bündelt Echtzeitdaten zu Antwortcodes, Latenz, Traffic-Pfaden und Request-Traces und ermöglicht es dir, von „irgendetwas stimmt nicht“ schnell zu einer Lösung an der eigentlichen Fehlerquelle zu kommen. Nutze diesen Leitfaden, um die Oberfläche zu meistern, nach Performance-Engpässen zu filtern und deinen Traffic-Fluss zu überprüfen.
Aktivierung des Request Browsers
Der Request Browser ist standardmäßig nicht aktiviert. Um ihn nutzen zu können, muss das Monitoring zunächst sowohl für die Resource Group (Team) als auch für jede einzelne Landscape, in der du es verwenden möchtest, aktiviert werden.
Für weitere Hilfe dazu findest du Informationen in unserem Artikel Monitoring aktivieren.
Info: Nur Admins der Resource Group (Team) können das Monitoring aktivieren.
Architekturübersicht
Entsprechende barrierefreie Textbeschreibung
Nutzung des Request Browsers
Was zeichnet der Request Browser auf?
Request Logs erfassen jede externe Interaktion mit dem öffentlichen Endpunkt deiner Anwendung:
- Wichtige Kennzahlen: Untersuche und verstehe zentrale Request-Details, einschließlich der End-to-End-Latenz (Antwortzeit), des HTTP-Statuscodes (200, 404, 500) und des aufgerufenen Ressourcenpfads.
- Nutzer-Rückverfolgbarkeit: Bringe bestimmte Requests mit Nutzersitzungen oder Client-IP-Adressen in Verbindung, um gezielt zu debuggen und problematische Traffic-Quellen zu identifizieren.
Datenaufbewahrung und Speicherung
- Aufbewahrungszeitraum: Traces werden für 14 Tage aufbewahrt. Nach diesem Zeitraum werden die Daten automatisch gelöscht.
- Speicherlimits: Für die Trace-Speicherung gilt ein Speicherkontingent. Wird das zugewiesene Kontingent überschritten, werden die ältesten Logs automatisch überschrieben, um Platz für neu eingehenden Traffic zu schaffen.
Warnung: Das Deaktivieren des Monitorings auf Ebene der Resource Group (Team) löst eine sofortige, endgültige Löschung aller historischen Logs für diese Gruppe aus. Diese Aktion kann nicht widerrufen werden.
Typische Anwendungsfälle
- API-Performance-Audit: Filtere Logs so, dass nur Requests an deine
/api-Endpunkte mit einer Latenz von mehr als 500 ms angezeigt werden, um Performance-Regressionen nach einem Deployment zu erkennen. - Traffic-Validierung: Überprüfe, ob pfadbasierte Routing-Regeln eingehenden Traffic korrekt an die vorgesehenen Services verteilen (z. B. dass sämtlicher Traffic an
/docsan den statischen Service geht).
Request Logs sind für das Debugging außerhalb der Anwendungsebene unerlässlich:
- Fehlerdiagnose: Erkenne und analysiere schnell Muster in fehlgeschlagenen 4xx- (Client-) und 5xx- (Server-) Antworten, um Konfigurations- oder Anwendungsprobleme zu identifizieren. (Siehe:
network-and-connection-issues.md) - Performance-Engpässe: Identifiziere langsame Requests (hohe Latenz), um API-Endpunkte zu ermitteln, die optimiert werden müssen.
Der Request Browser im Überblick
Zeitstempel: Der genaue Zeitpunkt (bis auf die Millisekunde), zu dem der Request von der Plattform empfangen wurde.
Service: Die interne Anwendung oder Komponente (z. B. api, frontend), die den Request bearbeitet hat.
Methode: Das verwendete HTTP-Verb (GET, POST usw.), das die Art des Requests angibt.
Ressource: Der konkrete aufgerufene Endpunkt oder Dateipfad (z. B. /shorten oder /favicon.ico).
Dauer: Die gesamte Round-Trip-Zeit in Millisekunden (ms) vom Request bis zur Antwort.
Status: Der HTTP-Antwortcode.
| Severity Code | Bedeutung |
|---|---|
| 200 | Erfolgreich |
| 304 | Nicht verändert |
| 404 | Nicht gefunden |
| 500 | Serverfehler |
| 504 | Gateway-Timeout |
Filtern und Analysieren (Schritt für Schritt)
- Navigiere über die Seitenleiste zum Tab Request Browser.
- Auswählen: Wähle den Tab Request Browser.
Tipp: Werden keine Daten angezeigt? Das ist meist der Fall, wenn keine Requests deinen Kriterien entsprechen. Passe deine Filter an oder wähle einen anderen Zeitraum.
- Filtere nach Servicename, Ressource, Status oder Methode.
- Zeitfilterung: Nutze die Zeitauswahl, um Logs aus einem bestimmten historischen Zeitraum zu untersuchen.
- Zugehörige Logs: Über die Aktionsschaltfläche kannst du problemlos zu den Logs wechseln, die zu einem Request gehören.
Codesphere öffnet einen neuen Tab im Log Browser, der automatisch auf das entsprechende Zeitfenster und den entsprechenden Service gefiltert ist.
Hinweis zur Trace-Korrelation: Für eine exakte 1:1-Zuordnung zwischen Traces und Logs sollte deine Anwendung die OpenTelemetry-Standards nutzen. Wird OpenTelemetry nicht erkannt, greift das System auf eine Zeitstempel-Korrelation zurück. Diese ist in der Regel zuverlässig, kann aber gelegentlich nahegelegene Logs anzeigen statt genau der Zeile, die für den Request verantwortlich ist.
- Geteilter Bildschirm: Zum einfacheren Debuggen kannst du den Log Browser und den Request Browser nebeneinander anzeigen.
Info: Damit der Log Browser funktioniert, muss die Logerfassung aktiv sein.
Fehlerbehebung & Fehlermeldungen
| Fehlercode/Meldung | Ursache | Lösung/Beispiel |
|---|---|---|
| Übermäßig viele 404-Fehler bei statischen Assets | Der Request-Pfad unterscheidet zwischen Groß- und Kleinschreibung, oder die statischen Dateien waren nicht im Deployment-Artefakt enthalten. | Stelle sicher, dass alle Asset-Pfade korrekt sind. Bei Servern mit Groß-/Kleinschreibungsunterscheidung sollte die Pfadübereinstimmung exakt sein. |
| Alle Requests zeigen 502 Bad Gateway | Der Service läuft nicht, oder die Port-Bindung ist fehlerhaft. | Prüfe umgehend die Service-Logs, um herauszufinden, warum die Anwendung nicht lauscht oder beim Start abgestürzt ist. |
Wie Codesphere Traces erfasst
Codesphere nutzt OpenTelemetry (OTel), ein branchenübliches Standard-Framework, zur Verarbeitung von Daten. OTel ist der Industriestandard für herstellerneutrale Telemetrie.
Häufig gestellte Fragen
-
Wie lange werden Logs aufbewahrt?
Traces werden für 14 Tage aufbewahrt. Nach diesem Zeitraum werden sie automatisch aus unserem System gelöscht. -
Wie werden Logs erfasst?
Wir nutzen OpenTelemetry (OTel). Dabei handelt es sich um ein schlankes, branchenübliches Framework, das mit den meisten modernen Anwendungsstacks kompatibel ist. -
Können Logs aus dem Request Browser exportiert werden?
Aktuell lassen sich Traces nicht direkt als Datei exportieren (z. B..csvoder.txt). Wenn du Logdaten für eine langfristige Auswertung speichern möchtest, empfehlen wir, die relevanten Textabschnitte manuell zu kopieren.Hast du einen Feature-Wunsch? Hilf uns, die Zukunft von Codesphere mitzugestalten. Neue Funktionen kannst du unter feedback.codesphere.com vorschlagen oder über die Community-Roadmap abstimmen.
-
Was ist der Unterschied zwischen Metrics und Traces?
- Wichtige Kennzahlen: Untersuche und verstehe zentrale Request-Details, einschließlich der End-to-End-Latenz (Antwortzeit), des HTTP-Statuscodes und des aufgerufenen Ressourcenpfads.
- Nutzer-Rückverfolgbarkeit: Bringe bestimmte Requests mit Nutzersitzungen oder Client-IP-Adressen in Verbindung, um gezielt zu debuggen.
-
Warum werden in der Tabelle keine Daten angezeigt?
Diese Meldung erscheint in der Regel, wenn keine Requests den ausgewählten Kriterien entsprechen. Passe deine Filter an oder wähle einen anderen Zeitraum, um deinen Trace-Verlauf abzurufen.
-
Warum kann ich die Trace-Erfassung nicht aktivieren?
Das Monitoring muss zunächst für die Resource Group (Team) aktiviert werden. Das können nur Admins der Resource Group (Team) tun. Prüfe, ob du nur Member-Zugriff statt Admin-Zugriff hast.
