LogBrew-CLI-Referenz: Befehle und Filter

Die Open-Source-CLI von LogBrew liest Telemetrie und verwaltet Kontodaten aus einem Terminal. Installation, Anmeldung und häufige Aufgaben beschreibt der CLI-Leitfaden.

So funktioniert die CLI

Verwenden Sie im Terminal lesbaren Text. Verwenden Sie in Skripten und Coding-Agenten --json. Für Lesevorgänge im Konto brauchen Sie eine Kontoanmeldung. Führen Sie vor einer Anmeldung logbrew status --json aus. Eine Person muss die Autorisierung im Browser abschließen. Ingest-Schlüssel eines Projekts senden Telemetrie. Sie ersetzen keine Kontoanmeldung. Projekte erstellen, Schlüssel erstellen, Status, Priorität und Zuweisung eines Issues ändern, Bereitstellungen und Support-Aktualisierungen ändern Kontodaten. Prüfen Sie vor einem solchen Befehl, ob Aktion und Ziel stimmen. Führen Sie logbrew --help aus, um alle Befehle zu sehen. Hängen Sie --help an einen Befehl an, zum Beispiel logbrew read logs --help, um seine Flags zu sehen. Führen Sie logbrew help json für die JSON-Regeln aus.

Befehlsgruppe	Zweck
`login`, `whoami`, `me`, `logout`	Anmeldung starten, Kontoidentität lesen oder die lokale Sitzung beenden.
`status`, `health`, `doctor`, `version`, `examples`	Zugang, Projektbereitschaft, CLI-Version oder Beispiele für den ersten Start lesen.
`setup`	Lokale Manifeste lesen und einen Plan für die SDK-Einrichtung ausgeben. Ändert keine Dateien und führt den Installationsbefehl nicht aus.
`projects`	Den aktiven Projektkatalog lesen.
`projects repositories`	Verbundene Repositorys lesen oder Komponenten in einem Repository finden.
`projects create`, `projects keys create`	Ein Projekt erstellen oder einen Ingest-Schlüssel für ein bestehendes Projekt erstellen.
`projects setup`	Die beobachtete Einrichtung eines bestehenden Projekts festhalten.
`projects archive`, `projects delete`	Ein Projekt archivieren oder es nach Bestätigung endgültig löschen.
`usage`, `account usage`	Nutzung, Grenzen, Kontingentstatus und Termine für das Zurücksetzen lesen.
`mcp grants`, `mcp revoke`	Die mit Ihrem Konto verbundenen MCP-Clients nach Namen auflisten oder eine Verbindung widerrufen.
`read`	Logs, Issues, Aktionen, Releases, Metriken, Traces oder ein einzelnes Element lesen.
`explain`	Begrenzte Belege zu einem Issue, Log, einer Aktion, einem Trace, Span, einer Metrik oder einem Release lesen.
`investigate issue`	Belege zur Untersuchung eines Issues lesen oder eine Kandidaten-Bereitstellung prüfen.
`issues archive`, `issues resolve`, `issues reopen`	Den Status von 1 Issue oder von bis zu 100 Issues in einem Projekt setzen.
`issues priority`	Die Priorität von 1 Issue oder von bis zu 100 Issues in einem Projekt setzen.
`issues assign`, `issues unassign`	Die Zuweisung (ein Konto oder ein Team) von 1 Issue oder von bis zu 100 Issues in einem Projekt setzen oder entfernen.
`issues assignees`	Die Konten und Teams auflisten, denen in einem Projekt Issues zugewiesen werden können.
`issues owners`	Die vorgeschlagenen zuständigen Konten und Teams von 1 Issue auflisten.
`issues ownership`	Die Zuständigkeitsregeln und die CODEOWNERS-Datei eines Projekts lesen oder setzen.
`issues activity`	Den Änderungsverlauf von 1 Issue lesen.
`issues rule`, `logs rule`	Die Schweregrad-Regel von 1 Issue oder 1 Log-Signatur setzen.
`inbox`	Die Issues lesen, die andere Ihnen oder Ihren Teams zugewiesen haben, oder sie als gelesen markieren.
`set issue`, `resolve`, `close`, `ignore`, `reopen`	Den Status von 1 Issue setzen. `close` bedeutet `resolved`. `ignore` und `ignored` bedeuten `archived`.
`deploy`	Eine abgeschlossene Bereitstellung erfassen.
`debug-artifacts`	Native Debug-Dateien für Apple oder Android hochladen oder eine Image-Identität nachschlagen.
`analytics`	Übersicht, Eigenschaften, Vergleiche, Pfade, Trichter, Nutzerbindung oder Lebenszyklus lesen.
`support`	Support-Tickets erstellen, lesen, beantworten, schließen oder wieder öffnen.
`watch`	Live-Logs, Issues oder Aktionen streamen.

Doctor-Bericht eines Projekts lesen

Verwenden Sie eine Projekt-ID aus logbrew projects --json:

logbrew doctor --project "<project_id>" --json

Der Befehl liest den Projektzustand und ein aktuelles Log. Er erstellt kein Projekt, ändert keinen Schlüssel und hält keine Einrichtung fest. Der Bericht hat status, checks und next. Jede Prüfung hat check, status und next. Die Prüfungen sind api, auth, project, ingest_key, setup, telemetry und logs. Exit-Code 0 heißt, dass die CLI einen Bericht geschrieben hat. Er heißt nicht, dass das Projekt bereit ist. Lesen Sie den status des Berichts und jede Prüfung. Eine Prüfung mit not_checked ist nicht bestanden.

`status` des Berichts	Bedeutung und nächster Schritt
`auth_invalid`	Der Kontozugang fehlt oder ist ungültig. Eine Person führt `logbrew login` aus.
`project_missing`	Dieses Konto hat keinen Zugriff auf das Projekt. Verwenden Sie eine ID aus `logbrew projects --json`.
`api_unreachable`	Die API-Anfrage wurde nicht abgeschlossen. Prüfen Sie die Netzwerkverbindung und führen Sie den Befehl erneut aus.
`check_failed`	Eine Anfrage ist fehlgeschlagen oder ihre Antwort war ungültig. Führen Sie den Befehl unverändert erneut aus. Wenn er wieder fehlschlägt, nutzen Sie Problem melden.
`needs_ingest_key`	Das Projekt hat keinen aktiven Ingest-Schlüssel. Erstellen Sie einen Schlüssel nur mit der Berechtigung, das Projekt zu ändern.
`needs_setup`	Die SDK-Einrichtung ist nötig. Folgen Sie dem Schnellstart.
`needs_telemetry`	Die Einrichtung hat begonnen, aber LogBrew hat keine Telemetrie für das Projekt. Senden Sie ein Testereignis.
`ready`	Das Projekt hat einen aktiven Schlüssel und Telemetrie. Lesen Sie das Signal für Ihre Aufgabe.

Wenn das Lesen des Projekts gelingt, ist die Prüfung logs gleich visible, empty, unavailable, error oder invalid_response. Diese Prüfung ändert den status des Berichts nicht. Ein leeres Log-Ergebnis sagt nichts über andere Signale. Ein fehlgeschlagenes Lesen ist kein leeres Ergebnis. Nutzen Sie next als Hinweis zur Wiederherstellung. Es erteilt keine Erlaubnis, den Zustand von Konto oder Projekt zu ändern.

Beispiel: Kontozugang fehlt

Ohne Konto-Zugangsdaten stellt der Befehl keine API-Anfrage. Er schreibt diesen Bericht in die Standardausgabe und endet mit Code 0:

{
  "checks": [
    { "check": "api", "next": "run the API reachability check first", "status": "not_checked" },
    { "check": "auth", "next": "run logbrew login", "status": "missing" },
    { "check": "project", "next": "resolve the prior check first", "status": "not_checked" },
    { "check": "ingest_key", "next": "resolve the prior check first", "status": "not_checked" },
    { "check": "setup", "next": "resolve the prior check first", "status": "not_checked" },
    { "check": "telemetry", "next": "resolve the prior check first", "status": "not_checked" },
    { "check": "logs", "next": "resolve the prior check first", "status": "not_checked" }
  ],
  "next": "run logbrew login",
  "status": "auth_invalid"
}

Dieser Bericht unterscheidet sich von der Diagnose über die Projekt-API. Er enthält nicht die API-Felder state, setup_status oder next_action.

Filter

Filter	Befehle
`--project <project_id>`	logs, issues, actions, releases, metrics, traces, trace
`--release <release>`	logs, issues, actions, releases, metrics, traces, trace
`--environment <environment>`	logs, issues, actions, releases, metrics, traces, trace
`--service <service_name>`	logs, issues, actions, releases, metrics, traces
`--since 24h`	logs, issues, actions, releases, metrics, traces, analytics
`--until <RFC3339>`	logs, issues, actions, releases, metrics, traces, analytics
`--limit 100`	logs, issues, actions, releases, metrics, traces
`--severity error`	logs, watch
`--search checkout`	logs
`--trace <trace_id>`	logs
`--status unresolved`	issues (`unresolved`, `resolved`, `archived`)
`--priority high`	issues (`high`, `medium`, `low`)
`--assignee me`	issues (`me`, `none`, `my_teams`, eine Nutzer-ID oder `team:<team_id>`)
`--status error`	traces (`error`, `ok`)
`--min-duration-ms <milliseconds>`	traces
`--name <name>`	actions, metrics
`--user <distinct_id>`	actions

--since akzeptiert eine Dauer wie 24h oder 7d oder einen RFC-3339-Zeitstempel. --until akzeptiert einen RFC-3339-Zeitstempel. Es ist ein exklusives Ende und muss nach --since liegen. Ein einzelnes Issue nach ID akzeptiert kein --until. Der Schweregrad eines Logs ist info, warning, error oder critical. Der Issue-Status ist der Bearbeitungsstand des Issues, nicht sein Schweregrad. --status ignored ist ein älterer Name für --status archived. --status open bedeutet unresolved, und --status closed bedeutet resolved. --assignee none wählt Issues ohne Zuweisung aus, und --assignee my_teams wählt die Issues Ihrer Teams aus. Jeder andere Wert für --assignee schlägt mit invalid_assignee fehl. Die CLI akzeptiert auch diese Aliasse: --project-id, --env, --service-name, --trace-id, --distinct-id und --level für --severity. Verwenden Sie in neuen Skripten die Namen aus der Tabelle. Dieser Befehl liest die Fehler eines Tages:

logbrew read logs --severity error \
  --since 2026-10-01T00:00:00Z --until 2026-10-02T00:00:00Z --json

Die Projekt-ID wählt das Projekt aus. Der Dienstname wählt eine Komponente in diesem Projekt aus. Setzen Sie Werte mit Leerzeichen in Anführungszeichen:

logbrew read logs --project "<project_id>" \
  --service checkout-api --since 24h \
  --severity error --search "checkout failed" --json

Bei Suchtext, der mit einem Bindestrich beginnt, setzen Sie -- vor den Text:

logbrew logs --json -- --timeout

Vorkommen eines Issues auswählen

Ein Issue gruppiert passende Vorkommen. Lesen Sie das Issue für seinen Status, die Zahl der Vorkommen und die Zeitpunkte für „Zuerst gesehen“ und „Zuletzt gesehen“:

logbrew read issue "<issue_id>" --json

Nutzen Sie explain issue oder investigate issue für die Belege eines Vorkommens. Ohne --occurrence wählt LogBrew das empfohlene Vorkommen aus. Das ist nicht immer das neueste Ereignis. So lesen Sie das neueste Ereignis:

logbrew explain issue "<issue_id>" --occurrence latest --json

--occurrence akzeptiert auch recommended, first oder eine Vorkommens-ID, die LogBrew zurückgegeben hat. Diese Befehle lehnen Filter für Projekt, Release, Umgebung und Zeit ab. Lesen Sie den Zeitstempel des gewählten Vorkommens, bevor Sie Belege vergleichen. Die Felder der Belege beschreibt Issue untersuchen.

Status und Priorität eines Issues ändern

Verwenden Sie 1 Issue-ID, um 1 Issue zu ändern:

logbrew issues archive "<issue_id>" --json
logbrew issues priority high "<issue_id>" --json

archive setzt archived, resolve setzt resolved und reopen setzt unresolved. Die Priorität ist high, medium oder low. Eine Priorität, die Sie setzen, bleibt fest. Sonst folgt die Priorität dem Schweregrad des Issues. Um mehr als 1 Issue zu ändern, fügen Sie --project hinzu. Alle Issues müssen in diesem Projekt liegen. Ein Befehl ändert bis zu 100 Issues:

logbrew issues resolve "<issue_id_1>" "<issue_id_2>" \
  --project "<project_id>" --json

Das Ergebnis hat 1 Eintrag pro Issue. Jeder Eintrag ist updated, unchanged oder not_found. Ein Issue mit unchanged hatte den angefragten Wert schon. Nach einem Netzwerkfehler können Sie denselben Befehl erneut ausführen. Diese Befehle fragen nicht nach einer Bestätigung. Prüfen Sie zuerst die Issue-IDs. Lesevorgänge und Änderungen an Issues zeigen archived statt ignored sowie priority, priority_source und assignee jedes Issues. Siehe die Issue-Antwort.

Issues zuweisen

Ein Issue ist höchstens 1 Konto oder 1 Team zugewiesen. Listen Sie die Konten und Teams auf, die Sie in einem Projekt zuweisen können:

logbrew issues assignees --project "<project_id>" --json

Weisen Sie 1 Issue einem Konto, mit me sich selbst oder einem Team zu:

logbrew issues assign "<user_id>" "<issue_id>" --json
logbrew issues assign me "<issue_id>" --json
logbrew issues assign "team:<team_id>" "<issue_id>" --json

Entfernen Sie die Zuweisung:

logbrew issues unassign "<issue_id>" --json

Fügen Sie --project hinzu, um wie bei Status und Priorität bis zu 100 Issues dieses Projekts zu ändern. Ein Konto muss das Projekt lesen können, und ein Team muss zur Organisation des Projekts gehören. So finden Sie die Issues, die Ihnen oder Ihren Teams zugewiesen sind:

logbrew read issues --project "<project_id>" --assignee my_teams \
  --status unresolved --json

Die Textausgabe zeigt den Namen des zugewiesenen Kontos oder bei einem Team team #<slug>. Hat das Konto keinen Namen, zeigt sie die E-Mail-Adresse und danach die Nutzer-ID. Ein Issue ohne Zuweisung zeigt unassigned.

Zuständigkeit, Verlauf und Posteingang

logbrew issues owners "<issue_id>" --json
logbrew issues ownership --project "<project_id>" --json
logbrew issues ownership set --project "<project_id>" \
  --rules ownership.txt --codeowners .github/CODEOWNERS --json
logbrew issues activity "<issue_id>" --limit 50 --json
logbrew inbox --json
logbrew inbox read --json

issues owners listet die vorgeschlagenen zuständigen Konten und Teams und die geprüften Belege. issues ownership set sendet lokale Dateien mit jeweils höchstens 128 KiB. Eine leere Datei löscht ihren Text. issues activity und inbox nehmen --limit von 1 bis 200 sowie --cursor-time mit --cursor-id aus next_cursor an. Siehe Zuständigkeit eines Issues finden.

Schweregrad-Regeln setzen

logbrew issues rule "<issue_id>" warning --json
logbrew logs rule "<log_id>" info --ignore --json

Der Schweregrad ist info, warning, error, critical oder source. source zeigt wieder den erfassten Schweregrad. --ignore blendet passende Logs in der Standardliste der Logs aus. Ohne --ignore zeigt die Regel sie an.

Nächste Seite lesen

Logs, Issues, Aktionen, Metriken und Traces unterstützen Cursor-Paginierung. Releases nicht. Verwenden Sie --pagination cursor für die erste Seite:

logbrew read logs --project "<project_id>" --since 24h \
  --pagination cursor --limit 100 --json

Die Antwort hat logs und next_cursor. Ein next_cursor, der nicht null ist, hat time und id. Senden Sie diese Werte mit --cursor-time und --cursor-id:

logbrew read logs --project "<project_id>" --since 24h \
  --pagination cursor --limit 100 \
  --cursor-time "<returned_time>" \
  --cursor-id "<returned_id>" --json

Behalten Sie auf jeder Seite dieselben Filter und dasselbe Limit. Hören Sie auf, wenn next_cursor gleich null ist. Entscheiden Sie anhand des Cursors, nicht anhand der Zeilenzahl, ob es weitere Seiten gibt. Die letzte Seite kann leer sein:

{
  "logs": [],
  "next_cursor": null
}

Issues, Aktionen und Metriken nutzen dieselbe Form mit issues, actions oder metrics statt logs.

Live-Beobachtung

logbrew watch --json streamt Live-Logs, Issues und Aktionen. Fügen Sie logs, issues oder actions hinzu, um nur einen Typ zu streamen. tail, follow und stream sind Aliasse von watch. Watch unterstützt keine Traces oder Spans. Watch braucht --json. Ohne diese Option schreibt der Befehl watch streams JSON for agents und endet mit Code 1. Issue-Ereignisse von Watch zeigen ein archiviertes Issue als ignored, ohne Priorität. Lesen Sie das Issue, um seinen aktuellen Status und seine Priorität zu erhalten. Watch akzeptiert nur --severity, zum Beispiel --severity error,critical. logbrew watch actions akzeptiert kein --severity. Die CLI wendet diesen Filter an, nachdem sie die Ereignisse empfangen hat. Er verringert nicht, was der Server sendet. Watch hat keinen Filter für Projekt, Release, Umgebung oder Zeit. Für diese Filter nutzen Sie einen read-Befehl. Nach einer kurzen Unterbrechung wartet die CLI und verbindet sich dann neu.

Ergebnisse und Fehler lesen

Setzen Sie --json vor oder nach den Befehl. Lesen Sie den Exit-Code, bevor Sie die Ausgabe nutzen. Parsen Sie keine Ausgabe für Menschen. Sie kann sich zwischen Versionen ändern.

Exit-Code	Bedeutung
`0`	Erfolg. JSON steht in der Standardausgabe.
`1`	Der Befehl ist während der Ausführung fehlgeschlagen, zum Beispiel durch einen API- oder Netzwerkfehler.
`2`	Die CLI hat den Befehl vor der Ausführung abgelehnt.

Eine Erfolgsausgabe behält die Form der API-Antwort. Sie kann ein Array oder ein Objekt sein. Ohne Cursor-Paginierung gibt das Lesen von Logs ein Array zurück. Ein leeres Array heißt, dass keine Logs passen. Es ist kein Fehler. Fehler gehen in die Standardfehlerausgabe. Die Ausnahme ist debug-artifacts --json, das Fehler in die Standardausgabe schreibt. Ein JSON-Fehler hat ok, error, message und next. Verwenden Sie error als stabilen Fehlercode. Prüfen Sie next, bevor Sie den vorgeschlagenen Befehl ausführen. logbrew watch traces --json endet zum Beispiel mit Code 2 und schreibt:

{
  "ok": false,
  "error": "unknown_resource",
  "message": "unknown resource: traces",
  "next": "use logbrew traces for recent traces, or logbrew trace <trace_id> for one trace"
}

logbrew read logs --limit 0 --json endet mit Code 2 und schreibt:

{
  "ok": false,
  "error": "invalid_limit",
  "message": "invalid limit: 0",
  "next": "use --limit with a positive whole number"
}

Korrigieren Sie den Wert und führen Sie den Befehl erneut aus. Ein abgelehnter Befehl ist kein leeres Ergebnis. HTTP-Fehler beschreibt API-Fehler, direkte API-Anfragen die Referenz der Telemetrie-API.

​So funktioniert die CLI

​Doctor-Bericht eines Projekts lesen

​Beispiel: Kontozugang fehlt

​Filter

​Vorkommen eines Issues auswählen

​Status und Priorität eines Issues ändern

​Issues zuweisen

​Zuständigkeit, Verlauf und Posteingang

​Schweregrad-Regeln setzen

​Nächste Seite lesen

​Live-Beobachtung

​Ergebnisse und Fehler lesen