Codesphere Request Browser

Der Request Browser bündelt Echtzeitdaten zu Antwortcodes, Latenzzeiten, Traffic-Pfaden und Request-Traces und ermöglicht es, schnell von „irgendetwas stimmt nicht“ zu einer Lösung der eigentlichen Ursache zu gelangen. Nutze diese Anleitung, um die Oberfläche zu beherrschen, nach Performance-Engpässen zu filtern und deinen Traffic-Fluss zu überprüfen.

Wie der Request Browser aktiviert wird

Der Request Browser ist standardmäßig nicht aktiviert. Um ihn nutzen zu können, muss Monitoring zunächst sowohl in der Resource Group als auch in der jeweiligen Landscape aktiviert werden.

Hilfestellung dazu findest du in unserem Artikel Wie man Monitoring aktiviert.

info

Nur Resource-Group-Admins können Monitoring aktivieren.

Zweitens muss der Workspace Router der Landscape so konfiguriert werden, dass Traces an die Observability Platform exportiert werden. Dies lässt sich in der Router-Konfiguration einstellen.

CI.yml Schema 0.4 or earlier

Aktivierung der Trace-Erfassung im Request Browser.

CI.yml Schema 0.5

Aktivierung der Trace-Erfassung im Codesphere Router Service über den Landscape Config Editor.

info

Traces können nur automatisch auf Landscapes exportiert werden, die einen Codesphere Workspace Router enthalten. Landscapes mit einem Reactive als Landscape Gateway werden nicht unterstützt. Siehe Landscape Networking, um zu erfahren, wie du deine Landscape mit einem Workspace Router einrichtest.

Architekturübersicht

Entsprechende barrierefreie Textbeschreibung

Den Request Browser nutzen

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-Nachverfolgbarkeit: Verknüpfe bestimmte Requests mit Nutzersitzungen oder Client-IP-Adressen für gezieltes Debugging und die Identifizierung 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 der zugewiesene Speicherplatz überschritten, werden die ältesten Logs automatisch überschrieben, um Platz für neuen eingehenden Traffic zu schaffen.

warnung

Das Deaktivieren von Monitoring auf Resource-Group-Ebene löst eine sofortige, dauerhafte Löschung aller historischen Logs dieser Gruppe aus. Diese Aktion kann nicht rückgängig gemacht werden.

Typische Anwendungsfälle

• API-Performance-Audit: Filtere Logs so, dass nur Requests an deine /api-Endpunkte mit einer Latenz über 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. ob sämtlicher Traffic an /docs zum statischen Service geleitet wird).

Request-Logs sind essenziell für Debugging außerhalb der Anwendungsebene:

• Fehlerdiagnose: Erkenne und analysiere schnell Muster bei fehlgeschlagenen 4xx- (Client-) und 5xx- (Server-) Antworten, um Konfigurations- oder Anwendungsprobleme einzugrenzen. (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 auf einen Blick

Zeitstempel: Der genaue Zeitpunkt (bis auf die Millisekunde), an dem der Request von der Plattform empfangen wurde.

Service: Die interne Anwendung oder Komponente (z. B. api, frontend), die den Request verarbeitet 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.

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

Filtern und Analysieren (Schritt für Schritt)

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

   Keine Daten sichtbar?

   Das tritt üblicherweise auf, wenn keine Requests deinen Kriterien entsprechen. Passe deine Filter an oder wähle einen anderen Zeitraum.

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

3. Zeitfilter: Nutze die Zeitauswahl, um Logs aus einem bestimmten historischen Zeitraum zu untersuchen.
   

4. Zugehörige Logs: Zu einem Request gehörende Logs lassen sich über die Aktionsschaltfläche bequem aufrufen.
   

   Codesphere öffnet einen neuen Tab im Log Browser, der automatisch auf den relevanten Zeitraum und Service gefiltert ist.
   

   Hinweis zur Trace-Korrelation

   Um eine exakte 1:1-Zuordnung zwischen Traces und Logs sicherzustellen, sollte deine Anwendung OpenTelemetry-Standards nutzen. Wird OpenTelemetry nicht erkannt, greift das System auf eine Korrelation über Zeitstempel zurück. Diese ist in der Regel zuverlässig, kann aber gelegentlich nahegelegene Logs statt der exakten, für den Request verantwortlichen Zeile anzeigen.

5. Geteilter Bildschirm: Zum einfacheren Debuggen kannst du den Log Browser und den Request Browser nebeneinander anzeigen. Hinweis: Die Log-Erfassung muss aktiv sein, damit der Log Browser funktioniert.
   

Fehlerbehebung & Fehlermeldungen

Fehlercode/Meldung	Ursache	Lösung/Beispiel
Übermäßig viele 404-Fehler bei statischen Assets	Der Anfragepfad unterscheidet zwischen Groß-/Kleinschreibung, oder die statischen Dateien wurden nicht in das Deployment-Artefakt aufgenommen.	Stelle sicher, dass alle Asset-Pfade korrekt sind. Achte bei case-sensitiven Servern auf eine exakte Pfadübereinstimmung.
Alle Requests zeigen 502 Bad Gateway	Der Service läuft nicht, oder die Port-Bindung ist fehlerhaft.	Ü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 branchenübliches Standard-Framework, zur Datenverarbeitung. OTel ist der Industriestandard für herstellerneutrale Telemetrie.

Häufig gestellte Fragen

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

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

3. Lassen sich Logs aus dem Request Browser exportieren?
   Aktuell können Traces nicht direkt als Datei (z. B. .csv oder .txt) exportiert werden. Falls du Log-Daten zur langfristigen Auditierung sichern möchtest, 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 zentrale Request-Details, einschließlich der End-to-End-Latenz (Antwortzeit), des HTTP-Statuscodes und des aufgerufenen Ressourcenpfads.
• Nutzer-Nachverfolgbarkeit: Verknüpfe bestimmte Requests mit Nutzersitzungen oder Client-IP-Adressen für gezieltes Debugging.

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

6. Warum kann ich die Trace-Erfassung nicht aktivieren?
   Monitoring muss zunächst für die Resource Group aktiviert werden. Nur Resource-Group-Admins können dies tun. Prüfe, ob du nur Mitgliederzugriff statt Admin-Zugriff hast.