Skip to main content
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, 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: 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

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: 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:

​
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.
1

Zuweisbare Konten und Teams finden

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.
2

Issue zuweisen

Verwenden Sie me statt einer Nutzer-ID, um das Issue sich selbst zuzuweisen. Mit logbrew issues unassign "<issue_id>" --json entfernen Sie die Zuweisung. Ergänzen Sie --project, um bis zu 100 Issues eines Projekts zu ändern.
3

Eigene Issues lesen

Mit --assignee my_teams finden Sie die Issues Ihrer Teams, mit --assignee "team:<team_id>" 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

Das Ergebnis listet die vorgeschlagenen zuständigen Konten und Teams, die passendsten zuerst, und einen suggested_assignee. Jeder Eintrag hat eine source: 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:
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:
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

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

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

1

Ungelöste Issues in einem Bereich auflisten

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.
2

Issue-Details lesen

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.
3

Ein Vorkommen untersuchen

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.
4

Trace-Belegen nur folgen, wenn sie verfügbar sind

Lesen Sie den Trace nur, wenn correlations.trace.status gleich available ist. Verwenden Sie die Trace-ID aus der Antwort. Erfinden Sie nie eine.
Der Trace-Lesezugriff hat keinen Zeitfilter. Ist der Status not_linked, fahren Sie mit den Belegen des Issues fort.
5

Kandidaten-Bereitstellung prüfen

Verwenden Sie das untersuchte Vorkommen als Basis. Die Bereitstellungs-ID erhalten Sie aus den Bereitstellungsbelegen oder aus Ihrem Release-Prozess.
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.
6

Status, Priorität oder Zuständigkeit ändern

Führen Sie einen Befehl aus. Diese Befehle fragen nicht nach einer Bestätigung. Prüfen Sie deshalb zuerst die Issue-ID.
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 "<issue_id>" 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:
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: 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.

​
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 "<issue_id_1>" "<issue_id_2>" --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. 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.