> ## Documentation Index > Fetch the complete documentation index at: https://docs.logbrew.co/llms.txt > Use this file to discover all available pages before exploring further. # LogBrew-CLI-Referenz: Befehle und Filter > Finden Sie LogBrew-Befehle, Filter, Cursor-Paginierung, Live-Beobachtung, JSON-Ausgabe und Fehler. Die [Open-Source-CLI von LogBrew](https://github.com/LogBrewCo/cli) liest Telemetrie und verwaltet Kontodaten aus einem Terminal. Installation, Anmeldung und häufige Aufgaben beschreibt der [CLI-Leitfaden](/de/guides/cli). ## 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`: ```bash theme={null} logbrew doctor --project "" --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](/de/guides/report-a-problem). | | `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](/de/quickstart). | | `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`: ```json theme={null} { "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](/de/concepts/projects#diagnose-project-setup). Er enthält nicht die API-Felder `state`, `setup_status` oder `next_action`. ## Filter | Filter | Befehle | | - | - | | `--project ` | logs, issues, actions, releases, metrics, traces, trace | | `--release ` | logs, issues, actions, releases, metrics, traces, trace | | `--environment ` | logs, issues, actions, releases, metrics, traces, trace | | `--service ` | logs, issues, actions, releases, metrics, traces | | `--since 24h` | logs, issues, actions, releases, metrics, traces, analytics | | `--until ` | logs, issues, actions, releases, metrics, traces, analytics | | `--limit 100` | logs, issues, actions, releases, metrics, traces | | `--severity error` | logs, watch | | `--search checkout` | logs | | `--trace ` | 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:`) | | `--status error` | traces (`error`, `ok`) | | `--min-duration-ms ` | traces | | `--name ` | actions, metrics | | `--user ` | 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: ```bash theme={null} 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: ```bash theme={null} logbrew read logs --project "" \ --service checkout-api --since 24h \ --severity error --search "checkout failed" --json ``` Bei Suchtext, der mit einem Bindestrich beginnt, setzen Sie `--` vor den Text: ```bash theme={null} 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“: ```bash theme={null} logbrew read issue "" --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: ```bash theme={null} logbrew explain issue "" --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](/de/guides/investigate-an-issue). ## Status und Priorität eines Issues ändern Verwenden Sie 1 Issue-ID, um 1 Issue zu ändern: ```bash theme={null} logbrew issues archive "" --json logbrew issues priority high "" --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: ```bash theme={null} logbrew issues resolve "" "" \ --project "" --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](/de/reference/telemetry-response-shapes#issue-response). ## 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: ```bash theme={null} logbrew issues assignees --project "" --json ``` Weisen Sie 1 Issue einem Konto, mit `me` sich selbst oder einem Team zu: ```bash theme={null} logbrew issues assign "" "" --json logbrew issues assign me "" --json logbrew issues assign "team:" "" --json ``` Entfernen Sie die Zuweisung: ```bash theme={null} logbrew issues unassign "" --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: ```bash theme={null} logbrew read issues --project "" --assignee my_teams \ --status unresolved --json ``` Die Textausgabe zeigt den Namen des zugewiesenen Kontos oder bei einem Team `team #`. 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 ```bash theme={null} logbrew issues owners "" --json logbrew issues ownership --project "" --json logbrew issues ownership set --project "" \ --rules ownership.txt --codeowners .github/CODEOWNERS --json logbrew issues activity "" --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](/de/guides/issue-workflow#find-who-owns-an-issue). ## Schweregrad-Regeln setzen ```bash theme={null} logbrew issues rule "" warning --json logbrew logs rule "" 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: ```bash theme={null} logbrew read logs --project "" --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`: ```bash theme={null} logbrew read logs --project "" --since 24h \ --pagination cursor --limit 100 \ --cursor-time "" \ --cursor-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: ```json theme={null} { "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: ```json theme={null} { "ok": false, "error": "unknown_resource", "message": "unknown resource: traces", "next": "use logbrew traces for recent traces, or logbrew trace for one trace" } ``` `logbrew read logs --limit 0 --json` endet mit Code `2` und schreibt: ```json theme={null} { "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](/de/reference/api-errors), direkte API-Anfragen die [Referenz der Telemetrie-API](/de/reference/telemetry-api). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.