Codesphere Request Browser

Der Request Browser zentralisiert Echtzeitdaten zu Antwortcodes, Latenz, Traffic-Pfaden und Request-Traces und ermöglicht es dir, von „hier stimmt etwas nicht“ schnell zu einer Ursachenbehebung zu gelangen. Nutze diese Anleitung, um die Benutzeroberfläche zu verstehen, nach Performance-Engpässen zu filtern und deinen Traffic-Flow zu überprüfen.

Wie man den Request Browser aktiviert​

Der Request Browser ist standardmäßig nicht aktiviert. Um ihn nutzen zu können, muss Monitoring zunächst sowohl in der Resources Group (Team) als auch in jeder einzelnen Landscape, in der du ihn verwenden möchtest, aktiviert werden.

Weitere Hilfe dazu findest du in unserem Artikel Wie man Monitoring aktiviert.

Architekturübersicht​

Verwendung 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 kritische Request-Details, einschließlich End-to-End-Latenz (Antwortzeit), HTTP-Statuscode (200, 404, 500) und dem aufgerufenen Ressourcenpfad.
• Nachverfolgbarkeit von Nutzern: Korreliere bestimmte Requests mit Nutzersitzungen oder Client-IP-Adressen für gezieltes Debugging und die Identifikation problematischer Traffic-Quellen.

Datenaufbewahrung und Speicherung​

• Aufbewahrungszeitraum: Traces werden 14 Tage lang gespeichert. 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.

Häufige 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 identifizieren.
• Traffic-Validierung: Überprüfe, ob Path-Based-Routing-Regeln eingehenden Traffic korrekt an die vorgesehenen Services verteilen (z. B. dass der gesamte Traffic an /docs an den statischen Service geht).

Request-Logs sind essenziell für Debugging jenseits der Anwendungsebene:

• 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 einzugrenzen, 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 spezifische Endpunkt oder Dateipfad, auf den zugegriffen wurde (z. B. /shorten oder /favicon.ico).

Dauer: Die gesamte Round-Trip-Zeit in Millisekunden (ms) vom Request bis zur Antwort.

Status: Der HTTP-Antwortcode.

Schweregrad-Code	Bedeutung
200	Erfolg
304	Nicht verändert
404	Nicht gefunden
500	Serverfehler
504	Gateway-Timeout

Filtern und Analyse (Schritt für Schritt)​

1. Klicke innerhalb des Workspace auf die Schaltfläche Request Browser in der linken Seitenleiste.
   

   Keine Daten sichtbar?

   Dies tritt normalerweise auf, wenn keine Requests deinen Kriterien entsprechen. Passe deine Filter an oder wähle einen anderen Zeitraum aus.

2. Filtere nach Servicename, Ressource, Status oder Methode.
   

3. Zeitfilterung: Nutze den Zeitauswähler, um Logs aus einem bestimmten historischen Zeitraum zu untersuchen.
   

4. Zugehörige Logs: Zu einem Request zugehörige Logs können über die Aktionsschaltfläche einfach angezeigt werden.
   

   Codesphere öffnet einen neuen Tab im Log Browser, der automatisch auf das relevante Zeitfenster und den entsprechenden Service gefiltert ist.
   

   Hinweis zur Trace-Korrelation

   Um eine exakte 1:1-Zuordnung zwischen Traces und Logs zu gewährleisten, sollte deine Anwendung OpenTelemetry-Standards nutzen. Wird OpenTelemetry nicht erkannt, greift das System auf eine Zeitstempel-Korrelation zurück. Diese ist zwar meist genau, kann jedoch gelegentlich naheliegende Logs anzeigen statt der exakten Zeile, die für den Request verantwortlich ist.

5. Split Screen: Um das Debugging zu erleichtern, kannst du den Log Browser und den Request Browser nebeneinander anzeigen. Hinweis: Die Log-Erfassung muss aktiv sein, damit der Log Browser funktioniert.
   

Problembehebung & Fehler​

Fehlercode/Meldung	Ursache	Lösung/Beispiel
Übermäßig viele 404-Fehler bei statischen Assets	Der Request-Pfad ist case-sensitive, oder die statischen Dateien wurden nicht im Deployment-Artefakt enthalten.	Stelle sicher, dass alle Asset-Pfade korrekt sind. Bei case-sensitiven Servern muss die Pfadübereinstimmung exakt sein.
Alle Requests zeigen 502 Bad Gateway	Der Service läuft nicht, oder die Port-Bindung ist falsch konfiguriert.	Überprüfe sofort die Service Logs, um festzustellen, warum die Anwendung nicht lauscht oder warum sie beim Start abgestürzt ist.

Wie Codesphere Traces erfasst​

Codesphere nutzt OpenTelemetry (OTel), ein standardisiertes Industrie-Framework, zur Datenverarbeitung. OTel ist der Industriestandard für anbieterneutrale Telemetrie.

Häufig gestellte Fragen​

1. Wie lange werden Logs aufbewahrt?
   Traces werden 14 Tage lang aufbewahrt. Nach diesem Zeitraum werden sie automatisch aus unserem System gelöscht.
   

2. Wie werden Logs erfasst?
   Wir nutzen OpenTelemetry (OTel). Es handelt sich um ein leichtgewichtiges, branchenübliches Framework, das mit den meisten modernen Anwendungs-Stacks kompatibel ist.

3. Können Logs aus dem Request Browser exportiert werden?
   Aktuell können Traces nicht direkt als Datei exportiert werden (z. B. .csv oder .txt). Wenn du Log-Daten für eine langfristige Prüfung sichern musst, empfehlen wir, die relevanten Textabschnitte manuell zu kopieren.
   

   Hast du einen Feature-Wunsch?

   Hilf uns, die Zukunft von Codesphere mitzugestalten. Du kannst neue Features vorschlagen oder über die Community-Roadmap abstimmen unter feedback.codesphere.com.

4. Was ist der Unterschied zwischen Metrics und Traces?
   

• Wichtige Kennzahlen: Untersuche und verstehe kritische Request-Details, einschließlich End-to-End-Latenz (Antwortzeit), HTTP-Statuscode und dem aufgerufenen Ressourcenpfad.
• Nachverfolgbarkeit von Nutzern: Korreliere bestimmte Requests mit Nutzersitzungen oder Client-IP-Adressen für gezieltes Debugging.

5. Warum sehe ich keine Daten in der Tabelle?
   Diese Meldung erscheint normalerweise, wenn keine Requests deinen ausgewählten Kriterien entsprechen. Passe deine Filter an oder wähle einen anderen Zeitraum aus, um deinen Trace-Verlauf abzurufen.
   
   

6. Warum kann ich die Trace-Erfassung nicht aktivieren?
   Monitoring muss zunächst für die Resource Group (Team) aktiviert werden. Dies können nur Resource Group (Team) Admins tun. Überprüfe, ob du nur Mitglieder-Zugriff statt Admin-Zugriff hast.