Fehlerbehebung bei fehlenden Anwendungs-Logs

Nutzen Sie diese Seite, wenn Telemetrie fehlt, unvollständig oder zu breit ist. Prüfen Sie zuerst den Zugang. Halten Sie dann Projekt, Dienst, Release, Umgebung und Zeitraum fest, während Sie die Ursache suchen.

Fügen Sie für Agenten-Abläufe --json hinzu. Eine fehlgeschlagene Prüfung gibt ein stabiles Feld next zurück.

Mit den schnellen Prüfungen beginnen

Symptom	Erste Prüfung	Nächster Schritt
CLI ist nicht angemeldet	`logbrew status --json`	Eine Person führt `logbrew login` aus.
Ein Projekt fehlt	`logbrew projects --json`	Verwenden Sie eine ID aus der Projektliste.
Stand der Einrichtung ist unklar	`logbrew doctor --project "<project_id>" --json`	Folgen Sie dem zurückgegebenen Wert `next`.
Logs sind leer	Logs für genau dieses Projekt und diesen Zeitraum lesen	Prüfen Sie andere Signaltypen getrennt.
Ergebnisse sind zu breit	Filter für Projekt, Dienst, Release und Umgebung hinzufügen	Behalten Sie bei jedem Lesen denselben Bereich.
Ein Trace fehlt	Die Issue-Details lesen	Lesen Sie einen Trace nur, wenn die Antwort eine Trace-ID enthält.
JavaScript-Frames zeigen gebauten Code	Das Paar aus Build und Source Map prüfen	Folgen Sie JavaScript-Source-Maps.
Ein MCP-Agent kann ein Projekt nicht lesen	Die freigegebenen Projekte prüfen	Folgen Sie Verbindungsprobleme mit MCP.

Fehlende erste Telemetrie finden

Führen Sie diese reinen Lesebefehle aus, bevor Sie die SDK-Konfiguration ändern:

logbrew version --json
logbrew status --json
logbrew projects --json
logbrew doctor --project "<project_id>" --json

logbrew doctor prüft API-Zugang, Authentifizierung, Projekt, Ingest-Schlüssel, Einrichtung, Telemetrie und Sichtbarkeit der Logs. Der Befehl ändert das Projekt nicht. Lesen Sie den Gesamtwert status und jede Prüfung im Doctor-Bericht. Exit-Code 0 heißt nicht, dass jede Prüfung bestanden wurde.

Doctor-Status	Nächster Schritt
`needs_ingest_key`	Erstellen Sie einen Ingest-Schlüssel für das Projekt. Siehe Ingest-Schlüssel rotieren.
`needs_setup`	Schließen Sie die SDK-Einrichtung ab. Siehe SDK-Integration.
`needs_telemetry`	Senden Sie ein sicheres Testereignis aus der App und führen Sie den Doctor erneut aus.
`ready`	Lesen Sie aktuelle Logs, Issues, Releases oder Traces.

Der Bericht kann auch den Status auth_invalid, project_missing, api_unreachable oder check_failed haben. Der Doctor-Bericht nennt für jeden den nächsten Schritt. Ein Projekt mit ready kann trotzdem keine Logs haben, denn jeder Signaltyp ist eigenständig. Die Prüfung logs kann empty oder unavailable sein. Ein fehlgeschlagenes Lesen der Logs ist kein leeres Ergebnis.

Ein sicheres Testereignis senden

Senden Sie mit dem installierten SDK ein Test-Log mit einer eindeutigen Nachricht. Nehmen Sie kein Token, keine Nutzerdaten und keinen Anfrage-Body auf. Notieren Sie Projekt-ID, Dienst, Umgebung, Release, Startzeit in UTC und SDK-Version. Warten Sie die Zustellung ab und lesen Sie dann einen kurzen Zeitraum im selben Projekt. Senden Sie keine weiteren Testereignisse, solange die Zustellung aussteht.

Fehlende Logs finden

Lesen Sie zuerst einen kleinen, exakten Bereich:

logbrew read releases --project "<project_id>" --environment production --json
logbrew read logs --project "<project_id>" --environment production \
  --release checkout@1 --since 1h --limit 20 --json

Prüfen Sie diese Punkte der Reihe nach:

Die Projekt-ID gehört zur App, die das Ereignis gesendet hat.
Dienst, Release und Umgebung stimmen exakt überein, auch bei Groß- und Kleinschreibung und Leerzeichen.
Der Zeitraum enthält die Ereigniszeit. LogBrew gibt Ereigniszeiten in UTC zurück. --until ist eine exklusive Obergrenze.
Kein Such- oder Schweregradfilter blendet das Ereignis aus.
Die App hat den Signaltyp gesendet, den Sie lesen. Ein Log erzeugt weder ein Issue noch einen Trace.

Wenn das Ereignis weiter fehlt, entfernen Sie einen Filter nach dem anderen:

Behalten Sie das Projekt und vergrößern Sie den Zeitraum.
Entfernen Sie den Release-Filter.
Entfernen Sie den Umgebungsfilter.
Entfernen Sie den Dienstfilter.
Entfernen Sie Such- und Schweregradfilter.

Hören Sie auf, sobald das Ereignis erscheint. Der zuletzt entfernte Filter passt nicht zur Konfiguration der App. Lesen Sie nicht alle Projekte statt des konfigurierten Projekts.

Ergebnis	Was es zeigt	Nächste Prüfung
Keine Zeilen in einem Projekt	Kein Treffer in diesem Bereich	Prüfen Sie Zeit und Filter.
Logs, aber keine Issues	Kein gruppierter Fehler passt zu den Filtern	Prüfen Sie, ob die App einen Fehler gesendet hat.
Issue ohne Trace	Das Vorkommen hat keinen nutzbaren Trace-Link	Lesen Sie den Trace-Status in der Untersuchung des Issues.
Ein Release, aber keine Logs	Das Release hat andere Signale, aber keine Logs in diesem Bereich	Vergleichen Sie die Zahlen in `logbrew read releases`. Lesen Sie jeden Signaltyp im selben Projekt.
Ereignis erscheint, nachdem Sie einen Filter entfernt haben	Dieser Filter hat das Ereignis ausgeschlossen	Korrigieren Sie den Filter oder den Wert in der App.

Eine Ergebnisseite ist keine Gesamtzahl. Mit --pagination cursor machen Sie mit dem zurückgegebenen next_cursor weiter und behalten dieselben Filter. Siehe Cursor-Paginierung.

Ansicht im Dashboard prüfen

Das Dashboard zeigt eine Momentaufnahme jeder Liste. Schalten Sie in der Log-Ansicht Live-Logs ein, um neue Logs beim Eintreffen hinzuzufügen. Andere Ansichten aktualisieren sich nicht live. Laden Sie die Seite neu, um eine neue Momentaufnahme zu erhalten. Eine veraltete Momentaufnahme ist etwas anderes als ein leeres Ergebnis. LogBrew speichert nur die Telemetrie, die die App sendet. Entfernen Sie Zugangsdaten, Anfrage-Bodys, Query-Werte und personenbezogene Daten vor der Zustellung. Prüfen Sie Ihre Feldauswahl mit Erfasste Daten steuern.

Issues und Traces prüfen

Verwenden Sie eine Issue-ID oder Trace-ID, die LogBrew zurückgegeben hat. Erfinden Sie nie eine.

logbrew read issues --project "<project_id>" --environment production \
  --status unresolved --since 24h --json
logbrew read issue "<issue_id>" --json
logbrew read trace "<trace_id>" --project "<project_id>" --json
logbrew read logs --trace "<trace_id>" --project "<project_id>" --json

--status akzeptiert unresolved, resolved und archived. ignored wählt dieselben Issues aus wie archived. Issue-Status und Trace-Status sind verschieden. Die Trace-Statuswerte not_linked, not_found und unavailable haben unterschiedliche Bedeutungen. Jeden Wert erklärt Issue untersuchen. Lesen Sie das Issue und seine Logs, bevor Sie es lösen, archivieren oder wieder öffnen.

CLI- und API-Fehler behandeln

Im JSON-Modus enthält ein CLI-Fehler ok, error, message und next:

{
  "ok": false,
  "error": "not_logged_in",
  "message": "not logged in: run logbrew login",
  "next": "run logbrew login"
}

Wenn die API einen Fehler zurückgibt, ist error gleich api_error. Der Fehler hat dann auch status (den HTTP-Status), api_code (den code der API), api_error und api_next. Bei einem Fehler rate_limited hat er außerdem retry_after_seconds. Die CLI wiederholt nicht automatisch.

Status oder Fehler	Wiederherstellung
`not_logged_in` oder HTTP `401`	Eine Person führt `logbrew login` aus. Wiederholen Sie dann das Lesen.
HTTP `403`	Verwenden Sie die richtigen Zugangsdaten für das Projekt. Eine Änderung an einem Issue braucht außerdem die Berechtigung, Issues im Projekt zu verwalten. Zeigen Sie den Wert der Zugangsdaten nicht an.
HTTP `404`	Verwenden Sie eine aktuelle Projekt-, Issue- oder Trace-ID aus einer Antwort.
HTTP `422`	Korrigieren Sie das genannte Feld.
HTTP `429` mit `rate_limited`	Warten Sie `retry_after_seconds` ab und wiederholen Sie dann einmal.
HTTP `429` mit einem anderen Code	Stoppen Sie automatische Wiederholungen. Folgen Sie `api_next`.
HTTP `5xx`	Warten Sie, wiederholen Sie ein Lesen und melden Sie das Problem, wenn es bleibt.

Jeden Fehlercode erklärt API-Fehler.

Kompromittiertes Konto absichern

Wenn eine andere Person ein Konto-Zugriffstoken, ein Refresh-Token oder ein Sitzungs-Cookie haben könnte, melden Sie alle LogBrew-Clients ab. Folgen Sie dem Ablauf für die kontoweite Abmeldung. Eine Person muss diese Aktion freigeben. logbrew logout und eine Abmeldung im Browser beenden nur einen Client. Sie reichen also nicht. Die kontoweite Abmeldung beendet auch jede MCP-Verbindung, die vorher freigegeben wurde. Löschen Sie nach dem Erfolg die lokalen LogBrew-Zugangsdaten auf jedem Client und melden Sie sich von einem vertrauenswürdigen Client neu an. Geben Sie MCP-Clients erst wieder frei, wenn Sie ihnen vertrauen. Wenn die Antwort verloren geht, melden Sie nicht, dass alle Clients abgemeldet sind, und wiederholen Sie die Anfrage nicht automatisch. Die kontoweite Abmeldung rotiert keine Ingest-Schlüssel der Projekte. Wenn ein Ingest-Schlüssel offengelegt wurde, rotieren Sie den Ingest-Schlüssel.

Fehlerbehebung sicher halten

Verwenden Sie für Lesevorgänge der CLI Konto-Zugangsdaten. Verwenden Sie Ingest-Zugangsdaten für ein Projekt nur für Schreibvorgänge des SDK. Legen Sie keine Tokens, Authorization-Header, rohen Logs, Kundendaten, Anfrage-Bodys, lokalen Pfade oder Quellcode in einen Befehl, einen Chat oder ein Support-Ticket. Bevor Sie ein Problem melden, wiederholen Sie ein Lesen mit dem kleinsten Bereich, der noch fehlschlägt. Notieren Sie den Befehl ohne Werte der Zugangsdaten, den Fehlercode, die Projekt-ID und die Filterwerte. Wenn die Prüfungen das Problem nicht lösen, nutzen Sie Problem melden.

Schnellstart

Senden und lesen Sie das erste sichere Ereignis.

CLI-Leitfaden

Verwenden Sie exakte Filter und JSON-Ausgabe.

Issue untersuchen

Lesen Sie die Belege eines Issues, bevor Sie den Status ändern.

API-Fehler

Reagieren Sie richtig auf jeden Fehlercode.

Einstieg

Konzepte

Installieren und senden

Untersuchen

CLI und Agenten

Support

Fehlerbehebung bei fehlenden Anwendungs-Logs

Mit den schnellen Prüfungen beginnen

Fehlende erste Telemetrie finden

Ein sicheres Testereignis senden

Fehlende Logs finden

Ansicht im Dashboard prüfen

Issues und Traces prüfen

CLI- und API-Fehler behandeln

Kompromittiertes Konto absichern

Fehlerbehebung sicher halten

Verwandte Seiten

Schnellstart

CLI-Leitfaden

Issue untersuchen

API-Fehler

​Mit den schnellen Prüfungen beginnen

​Fehlende erste Telemetrie finden

​Ein sicheres Testereignis senden

​Fehlende Logs finden

​Ansicht im Dashboard prüfen

​Issues und Traces prüfen

​CLI- und API-Fehler behandeln

​Kompromittiertes Konto absichern

​Fehlerbehebung sicher halten

​Verwandte Seiten

Schnellstart

CLI-Leitfaden

Issue untersuchen

API-Fehler

Mit den schnellen Prüfungen beginnen

Fehlende erste Telemetrie finden

Ein sicheres Testereignis senden

Fehlende Logs finden

Ansicht im Dashboard prüfen

Issues und Traces prüfen

CLI- und API-Fehler behandeln

Kompromittiertes Konto absichern

Fehlerbehebung sicher halten

Verwandte Seiten