> ## 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. # Issues in LogBrew triagieren und lösen > Verwalten Sie Issues in LogBrew. Lesen Sie die Belege eines Vorkommens, finden Sie heraus, wer zuständig ist, und lösen, archivieren, öffnen, priorisieren oder weisen Sie Issues einer Person oder einem Team zu. Ein Issue gruppiert Fehlervorkommen mit demselben Fingerprint. Lesen Sie die Zusammenfassung der Gruppe und ein Vorkommen, bevor Sie Status, Priorität oder Zuweisung ändern. Eine Änderung an Status, Priorität oder Zuweisung hält eine Entscheidung des Teams fest. Sie repariert keine Software und schreibt keine erfassten Ereignisse um. Installieren Sie die [LogBrew-CLI](/de/guides/cli), und führen Sie `logbrew login` aus, bevor Sie beginnen. ## Issues und Vorkommen Eine Issue-Liste liefert eine Zusammenfassung der Gruppe, kein vollständiges Ereignis. Lesen Sie diese Felder, bevor Sie die Details öffnen: | Feld | Bedeutung | | - | - | | `title` | Erfasster Titel des Fehlers. | | `severity` | Erfasster Schweregrad. | | `triage.effective_severity` | Schweregrad, den LogBrew nach den Issue-Regeln verwendet. `severity` behält den erfassten Wert. `triage.rule_applied` ist `true`, wenn eine Regel greift. | | `occurrence_count` | Anzahl der gespeicherten Vorkommen in der Gruppe. | | `first_seen_at` | Zeitpunkt des frühesten gespeicherten Vorkommens. | | `last_seen_at` | Zeitpunkt des neuesten gespeicherten Vorkommens. | | `project_id` | Projekt, das das Issue enthält. | | `service_name` | Dienst des neuesten Vorkommens. | | `release` | Release des neuesten Vorkommens. | | `environment` | Umgebung des neuesten Vorkommens. | | `status` | Workflow-Status des Issues. Siehe [Statuswerte](#status-values). | | `priority` | Reihenfolge des Issues in der Triage. Siehe [Priorität](#priority). | | `priority_source` | `manual`, wenn eine Person die Priorität gesetzt hat. `derived`, wenn sie dem Schweregrad folgt. | | `assignee` | Konto oder Team, das für den nächsten Schritt zuständig ist, oder `null`. Siehe [Issues zuweisen](#assign-issues). | Die Anzahl der Vorkommen ist keine Anzahl betroffener Nutzer. Anzahlen und Zeitpunkte gelten für den gelieferten Bereich, nicht für den gesamten Fehlerverlauf. Ein Filter `--since` oder `--until` begrenzt die Vorkommen, die LogBrew zählt. Wenn Sie eine Anzahl melden, nennen Sie auch die Filter, die sie ergeben haben. ## Statuswerte | Status | Bedeutung | | - | - | | `unresolved` | Das Issue braucht eine Entscheidung. | | `resolved` | Das Team hat das Issue als gelöst markiert. Der Status beweist die Korrektur nicht. | | `archived` | Das Team hat das Issue aus der aktiven Triage genommen. | `archived` hieß früher `ignored`. Beide Namen wählen dieselben Issues aus, und beide werden als Eingabe akzeptiert. `logbrew read`, `logbrew issues` und die API-Versionen 2 und 3 zeigen `archived`. API-Version 1 (der Standard), der Live-Watch-Stream und die Antwort der Issue-Untersuchung zeigen `ignored`. Das Dashboard zeigt die Status als „Ungelöst“, „Gelöst“ und „Archiviert“. Der Status gilt für das ganze Issue, nicht für ein einzelnes Vorkommen. Der Schweregrad zeigt die Dringlichkeit, der Status hält die Entscheidung fest. Halten Sie beides getrennt. Ein Issue mit `critical` kann nach einer geprüften Korrektur `resolved` sein. Ein Issue mit `archived` behält seinen erfassten Schweregrad. LogBrew öffnet ein gelöstes Issue nicht automatisch wieder. Kommt nach dem Lösen ein neues Vorkommen an, meldet die Untersuchung `lifecycle.effective_status` als `regressed`. Der `status` bleibt `resolved`, bis eine Person das Issue wieder öffnet. ## Priorität Die Priorität legt fest, in welcher Reihenfolge das Team Issues triagiert: | Priorität | Bedeutung | | - | - | | `high` | Untersuchen Sie das Issue zuerst. | | `medium` | Untersuchen Sie das Issue nach den Issues mit `high`. | | `low` | Das Issue kann warten. | Jedes Issue hat eine Priorität. Setzt niemand sie, folgt sie dem Schweregrad des Issues: `error` und `critical` ergeben `high`, `warning` ergibt `medium`, und `info` ergibt `low`. Ändert eine Issue-Regel den Schweregrad, folgt die Priorität `triage.effective_severity`. Dann ist `priority_source` gleich `derived`. Setzt eine Person die Priorität, bleibt sie fest, und `priority_source` ist `manual`. So listen Sie die Issues auf, die Sie zuerst untersuchen sollten: ```bash theme={null} logbrew read issues --project "" --status unresolved \ --priority high --since 24h --json ``` ## Issues zuweisen Weisen Sie ein Issue zu, um zu zeigen, wer für den nächsten Schritt zuständig ist. Ein Issue ist höchstens 1 Konto oder 1 Team zugewiesen. ```bash theme={null} logbrew issues assignees --project "" --json ``` `assignees` enthält jedes Konto, das das Projekt lesen darf, mit `user_id`, `name` und `email`. `teams` enthält jedes Team der Organisation des Projekts, mit `team_id`, `slug` und `name`. Ein Konto, das das Projekt nicht lesen darf, oder ein Team einer anderen Organisation können Sie nicht zuweisen. ```bash theme={null} logbrew issues assign "" "" --json logbrew issues assign "team:" "" --json ``` Verwenden Sie `me` statt einer Nutzer-ID, um das Issue sich selbst zuzuweisen. Mit `logbrew issues unassign "" --json` entfernen Sie die Zuweisung. Ergänzen Sie `--project`, um bis zu 100 Issues eines Projekts zu ändern. ```bash theme={null} logbrew read issues --project "" --assignee me \ --status unresolved --json ``` Mit `--assignee my_teams` finden Sie die Issues Ihrer Teams, mit `--assignee "team:"` die Issues eines Teams und mit `--assignee none` Issues, für die niemand zuständig ist. Zum Zuweisen von Issues brauchen Sie die Berechtigung, Issues im Projekt zu verwalten. Mit derselben Berechtigung ändern Sie Status, Priorität, Zuständigkeitsregeln sowie Issue- und Log-Regeln. Eigentümer und Admins der Organisation legen Teams an und wählen ihre Mitglieder. Ein Team gibt seinen Mitgliedern keinen Zugriff auf Projekte. Verliert ein Mitglied den Zugriff auf das Projekt, zeigen die ihm zugewiesenen Issues keine Zuweisung mehr. Wird ein Team gelöscht, zeigen die ihm zugewiesenen Issues ebenfalls keine Zuweisung mehr. Diese Issues erscheinen in Lesezugriffen mit `--assignee none`. Erhält das Mitglied wieder Zugriff, zeigen die Issues wieder dieses Mitglied, sofern niemand die Zuweisung in der Zwischenzeit geändert oder entfernt hat. ## Zuständigkeit eines Issues finden ```bash theme={null} logbrew issues owners "" --json ``` Das Ergebnis listet die vorgeschlagenen zuständigen Konten und Teams, die passendsten zuerst, und einen `suggested_assignee`. Jeder Eintrag hat eine `source`: | `source` | Bedeutung | | - | - | | `ownership_rule` | Eine Regel des Projekts passt zum Issue. `rule`, `line` und `matched` zeigen die Regel und das, worauf sie gepasst hat. | | `codeowners` | Eine Zeile der CODEOWNERS-Datei des Projekts passt zum Pfad eines Stack-Frames. | | `recent_activity` | Das Konto hat das Issue geändert oder war ihm zugewiesen. | `inputs` zählt die Stack-Frame-Pfade, Module, die Routenvorlage, die Tags und die Regeln, die LogBrew geprüft hat. Ist die Liste leer und zeigt `inputs` keine Pfade, fehlen dem Issue Belege für einen Abgleich. Das heißt nicht, dass niemand zuständig ist. Schreiben Sie Zuständigkeitsregeln in eine Textdatei, eine Regel pro Zeile: ```text theme={null} # type:pattern owner... path:src/payments/** ada@example.com #payments url:/checkout/* #web service:billing-api ada@example.com tags.region:eu-* #europe module:app.billing.* ada@example.com ``` Ein `path`-Muster passt auf das Ende eines Stack-Frame-Pfads. So passt `src/payments/**` auf Frames unter jedem Bereitstellungsverzeichnis. `*` passt auf beliebigen Text. Zuständig sind E-Mail-Adressen von Konten oder `#team-slug`. Die letzte passende Regel hat Vorrang. Senden Sie dann die Regeln, eine CODEOWNERS-Datei von GitHub oder beides: ```bash theme={null} logbrew issues ownership set --project "" \ --rules ownership.txt --codeowners .github/CODEOWNERS --json logbrew issues ownership --project "" --json ``` In CODEOWNERS bezeichnet eine E-Mail-Adresse ein Konto und `@org/team-slug` das Team mit diesem Slug. Regeln, die ein Konto ohne Zugriff auf das Projekt oder ein unbekanntes Team nennen, schlagen mit `422` fehl. CODEOWNERS-Einträge, die niemanden bezeichnen, erscheinen in `unresolved_owners`. Eine leere Datei löscht ihren Text. ## Verlauf eines Issues lesen ```bash theme={null} logbrew issues activity "" --json ``` Der Verlauf listet jede Änderung an Status, Priorität, Zuweisung und Schweregrad-Regel, die neueste zuerst, mit dem Konto, das sie vorgenommen hat. Er endet mit `first_seen`. Von einem Konto, das den Zugriff auf das Projekt verloren hat, bleibt nur die ID. Mit `--limit` und den Werten aus `next_cursor` lesen Sie weitere Einträge. ## Posteingang lesen ```bash theme={null} logbrew inbox --json logbrew inbox read --json ``` Der Posteingang listet die Issues, die andere Personen Ihnen oder Ihren Teams zugewiesen haben, die neuesten zuerst. `unread` zählt die Zuweisungen nach Ihrer Lesemarke. `logbrew inbox read` setzt die Lesemarke auf jetzt. LogBrew verschickt für diese Zuweisungen keine E-Mails. Der Posteingang zeigt nur Projekte, die Sie aktuell lesen dürfen. ## Empfohlener Ablauf ```bash theme={null} logbrew read issues --project "" --environment production \ --release api@1.2.3 --status unresolved --since 24h --json ``` Behalten Sie bei späteren Listen-Lesezugriffen dieselben Filter bei. Ein leeres Ergebnis bedeutet, dass kein Issue zu diesem Bereich passt. Es beweist nicht, dass das Projekt keine Fehler hat. Kopieren Sie die exakte Issue-ID, nicht den Titel. ```bash theme={null} logbrew read issue "" --json ``` Prüfen Sie, ob das gelieferte Projekt stimmt, bevor Sie fortfahren. Lesezugriffe liefern einen Snapshot. Lesen Sie das Issue erneut, bevor Sie den Status ändern. ```bash theme={null} logbrew investigate issue "" --occurrence recommended --json ``` Die Lesezugriffe auf Details und Untersuchung verwenden keine Listenfilter. Vergleichen Sie `subject.project_id`, `event.occurred_at`, Release und Umgebung mit Ihrem Bereich. Das empfohlene Vorkommen kann älter sein als das neueste. Für die vollständige Prüfung der Belege folgen Sie [Issue untersuchen](/de/guides/investigate-an-issue). Lesen Sie den Trace nur, wenn `correlations.trace.status` gleich `available` ist. Verwenden Sie die Trace-ID aus der Antwort. Erfinden Sie nie eine. ```bash theme={null} logbrew read trace "" --project "" --json logbrew read logs --trace "" --project "" \ --since 24h --json ``` Der Trace-Lesezugriff hat keinen Zeitfilter. Ist der Status `not_linked`, fahren Sie mit den Belegen des Issues fort. Verwenden Sie das untersuchte Vorkommen als Basis. Die Bereitstellungs-ID erhalten Sie aus den Bereitstellungsbelegen oder aus Ihrem Release-Prozess. ```bash theme={null} logbrew investigate issue "" verify \ --baseline-occurrence "" \ --candidate-deployment "" \ --json ``` Kein erneutes Auftreten im Beobachtungszeitraum beweist keine dauerhafte Korrektur. Ist `status` gleich `insufficient_traffic` oder `unavailable`, lassen Sie das Issue `unresolved`. Folgen Sie der gelieferten nächsten Aktion. Führen Sie einen Befehl aus. Diese Befehle fragen nicht nach einer Bestätigung. Prüfen Sie deshalb zuerst die Issue-ID. ```bash theme={null} logbrew issues resolve "" --json logbrew issues archive "" --json logbrew issues reopen "" --json logbrew issues priority low "" --json logbrew issues assign me "" --json ``` Ohne `--project` nimmt jeder Befehl 1 Issue-ID an. Prüfen Sie den Exit-Code sowie die gelieferten Werte `status`, `priority` und `assignee`. Fehlt das Ergebnis, lesen Sie das Issue erneut, bevor Sie die nächste Änderung vornehmen. Ältere Skripte können `logbrew set issue "" resolved` und die Kurzbefehle `resolve`, `ignore` und `reopen` verwenden. `ignore` setzt `archived`. ## Viele Issues auf einmal ändern Ergänzen Sie `--project`, um bis zu 100 Issues eines Projekts mit einem Befehl zu ändern: ```bash theme={null} logbrew issues archive "" "" "" \ --project "" --json ``` Der Befehl wendet eine Änderung auf jedes Issue an. Jede Issue-ID darf nur einmal vorkommen. Die CLI lehnt mehr als 100 IDs oder eine doppelte ID ab, bevor sie eine Anfrage sendet. Das Ergebnis hat 1 Eintrag pro Issue, in der Reihenfolge des Befehls: | Ergebnis | Bedeutung | | - | - | | `updated` | LogBrew hat die Änderung angewendet. | | `unchanged` | Das Issue hatte bereits den angeforderten Wert. | | `not_found` | Das Projekt hat kein Issue mit dieser ID. LogBrew hat dafür nichts geändert. | Jeder Eintrag hat `issue_id`, `outcome` und `issue`. `issue` ist das aktuelle Issue, bei `not_found` ist es `null`. Nach einem Netzwerkfehler können Sie denselben Befehl erneut ausführen. Bereits geänderte Issues zeigen dann `unchanged`. Für mehr als 100 Issues führen Sie weitere Befehle aus. Bei einem Ergebnis `not_found` kopieren Sie die ID erneut aus einer Issue-Liste dieses Projekts. Die API-Anfrage beschreibt [Issues gesammelt aktualisieren](/de/reference/telemetry-api#update-issues-in-bulk). ## Nächsten Status wählen * **Lassen Sie es `unresolved`**, wenn der Fehler aktiv ist oder die Korrektur nicht geprüft ist. Ein fehlender Trace ist kein Grund, ein Issue zu archivieren. * **Setzen Sie `resolved`**, wenn das Team die Belege für die Korrektur akzeptiert. Eine vorgeschlagene Korrektur ist kein Beleg. * **Setzen Sie `archived`** für einen akzeptierten Zustand oder ein Signal, das nur aus Tests stammt. Die Entscheidung gilt für jedes Vorkommen des Issue. Der Befehl hat kein Feld für einen Grund. Halten Sie den Grund deshalb in den Arbeitsunterlagen Ihres Teams fest. * **Öffnen Sie es mit `unresolved` wieder**, wenn nach dem Lösen ein neues Vorkommen ankommt. `lifecycle.regression.first_reappeared_occurrence` kennzeichnet es. Vergleichen Sie es mit dem Vorkommen, das Sie beim Lösen verwendet haben. Legen Sie kein anderes Issue an. ## Untersuchung übergeben Geben Sie der nächsten Person Verweise, keinen Rohdatenauszug von Ereignissen: * Issue-ID, Status, Priorität, Zuweisung und Schweregrad. * Projekt, Dienst, Umgebung und Release. * Zeitpunkt „Zuerst gesehen“, Zeitpunkt „Zuletzt gesehen“ und Anzahl der Vorkommen. * ID des ausgewählten Vorkommens und `occurrence_selection.reason`. * `fix.status`, `cause.status` und deren `provenance`. * Trace-Status und Trace-ID, falls verfügbar. * Reproduktionsstatus und fehlende Belege. * Ergebnis der Prüfung der Kandidaten-Bereitstellung. * Die nächste Aktion, die die Antwort geliefert hat. Kennzeichnen Sie vorgeschlagene Ursachen und Korrekturen als Vorschläge. ## CLI-Fehler beheben Prüfen Sie den Exit-Code des Prozesses, bevor Sie die Ausgabe parsen. Bei Erfolg geht JSON an die Standardausgabe. Ein Parse-Fehler endet mit dem Code `2`. Ein Laufzeitfehler endet mit dem Code `1`. JSON-Fehler gehen an die Standardfehlerausgabe und enthalten `ok: false`, `error`, `message` und `next`. Zeigen Sie `next` als Hinweis an. Führen Sie es nicht automatisch aus. Ein Beispiel: `logbrew issues archive "" "" --json` hat kein `--project`. Der Befehl endet vor einer Anfrage mit dem Code `2` und dem Fehler `invalid_issue_command`. Lehnt die API eine Anfrage ab, ist `error` gleich `api_error`. Lesen Sie `status` für den HTTP-Status und `api_code` für den API-Fehlercode. | Ergebnis | Behebung | | - | - | | `not_logged_in` | Bitten Sie eine Person, `logbrew login` auszuführen, und wiederholen Sie dann den Lesezugriff. | | `invalid_issue_command` | Korrigieren Sie den Befehl. Verwenden Sie `--project` für mehr als 1 Issue, höchstens 100 IDs und jede ID nur einmal. | | Ungültige Issue-ID | Kopieren Sie die exakte ID aus einer Issue-Liste oder einer Detailantwort. | | Issue nicht gefunden | Prüfen Sie das angemeldete Konto und das Projekt. | | Eine Änderung schlägt mit `status` `403` fehl | Das Konto darf in diesem Projekt keine Issues verwalten. Bitten Sie eine Person mit Zugriff. | | `invalid_assignee` | Der Filter `--assignee` nimmt `me`, `none`, `my_teams`, eine Nutzer-ID oder `team:` an. | | Eine Zuweisung schlägt mit `status` `422` und `api_code` `validation_failed` fehl | Das Konto darf das Projekt nicht lesen, oder das Team gehört nicht zur Organisation des Projekts. Wählen Sie einen Eintrag aus `logbrew issues assignees`. | | `invalid_ownership_command`, `invalid_ownership_file` | Korrigieren Sie den Befehl. Eine Zuständigkeitsdatei muss UTF-8-Text mit höchstens 128 KiB sein. | | `invalid_inbox_command` | Verwenden Sie `logbrew inbox` oder `logbrew inbox read`. | | `investigation_response_invalid` | Die Antwort hat die Validierung der CLI nicht bestanden. Wiederholen Sie den Vorgang einmal. Tritt der Fehler erneut auf, aktualisieren Sie die CLI oder melden Sie das Problem. Umgehen Sie die Validierung nicht. | | Trace-Status `not_linked` | Fahren Sie mit den Belegen des Issues fort. Lesen Sie keinen Trace. | | Trace-Status `unavailable` | Wiederholen Sie den Lesezugriff auf die Untersuchung später. | | Prüfung ergibt `insufficient_traffic` | Lassen Sie das Issue `unresolved`. Warten Sie auf Traffic im Kandidaten-Release, und prüfen Sie dann erneut. | Eine fehlgeschlagene Antwort beweist nicht, dass eine Änderung an Status, Priorität oder Zuständigkeit keine Wirkung hatte. Lesen Sie das Issue, bevor Sie es erneut versuchen. ## Was ein nützliches Issue ausmacht * Ein klarer Titel und eine lesbare Nachricht. * Ein stabiler Fingerprint. * Stackframes, wenn verfügbar. * Kontext zu Release, Umgebung und Dienst. * Trace-Kontext, wenn er mit dem Vorkommen erfasst wurde. * Kleine, relevante Attribute statt vollständiger Payload-Auszüge. Listenfilter und Antwortverträge beschreibt die [Referenz der Telemetrie-API](/de/reference/telemetry-api). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.