Skip to main content
Een issue groepeert foutvoorvallen met dezelfde vingerafdruk. Lees de samenvatting van de groep en één voorval voordat je de status, de prioriteit of de toewijzing wijzigt. Een wijziging van status, prioriteit of toewijzing registreert een beslissing van het team. Die repareert geen software en herschrijft geen vastgelegde events. Installeer de LogBrew CLI en voer logbrew login uit voordat je begint.

​
Issues en voorvallen

Een lijst met issues geeft een samenvatting per groep terug, geen volledig event. Lees deze velden voordat je de details opent: Het aantal voorvallen is geen aantal getroffen gebruikers. Aantallen en tijdstippen gelden voor het teruggegeven bereik, niet voor de volledige foutgeschiedenis. Een filter --since of --until beperkt de voorvallen die LogBrew telt. Meld je een aantal? Meld dan ook de filters die het hebben opgeleverd.

​
Statuswaarden

archived heette eerder ignored. Beide namen selecteren dezelfde issues, en beide worden als invoer geaccepteerd. logbrew read, logbrew issues en API-versies 2 en 3 tonen archived. API-versie 1 (de standaard), de stream bij live volgen en de response van een issueonderzoek tonen ignored. Het dashboard toont de statussen als ‘Onopgelost’, ‘Opgelost’ en ‘Gearchiveerd’. De status geldt voor het hele issue, niet voor één voorval. De ernst toont de urgentie, de status registreert de beslissing. Houd die twee gescheiden. Een issue met critical kan na een geverifieerde fix resolved zijn. Een issue met archived behoudt zijn vastgelegde ernst. LogBrew heropent een opgelost issue niet automatisch. Komt er na het oplossen een nieuw voorval binnen? Dan meldt het onderzoek lifecycle.effective_status als regressed. De status blijft resolved totdat een persoon het issue heropent.

​
Prioriteit

De prioriteit bepaalt in welke volgorde het team de triage van issues doet: Elk issue heeft een prioriteit. Stelt niemand die in? Dan volgt de prioriteit de ernst van het issue: error en critical worden high, warning wordt medium en info wordt low. Wijzigt een issueregel de ernst? Dan volgt de prioriteit triage.effective_severity. priority_source is dan derived. Stelt een persoon de prioriteit in? Dan blijft die vast en is priority_source gelijk aan manual. Zo toon je de issues die je als eerste moet onderzoeken:

​
Issues toewijzen

Wijs een issue toe om te laten zien wie verantwoordelijk is voor de volgende stap. Een issue heeft 0 of 1 toewijzing: één account of één team.
1

Zoek op aan wie je kunt toewijzen

assignees bevat elk account dat het project kan lezen, met user_id, name en email. teams bevat elk team van de organisatie van het project, met team_id, slug en name. Je kunt een issue niet toewijzen aan een account dat het project niet kan lezen, of aan een team van een andere organisatie.
2

Wijs het issue toe

Gebruik me in plaats van een gebruikers-ID om het issue aan jezelf toe te wijzen. Gebruik logbrew issues unassign "<issue_id>" --json om de toewijzing op te heffen. Voeg --project toe om tot 100 issues van één project te wijzigen.
3

Lees je eigen issues

Gebruik --assignee my_teams voor de issues van je teams, --assignee "team:<team_id>" voor één team en --assignee none voor issues die aan niemand zijn toegewezen.
Om issues toe te wijzen, heb je het recht nodig om issues in het project te beheren. Met hetzelfde recht wijzig je de status, de prioriteit, de eigenaarsregels en de regels voor issues en logs. Eigenaren en beheerders van de organisatie maken teams aan en kiezen de leden. Een team geeft zijn leden geen toegang tot projecten. Verliest een lid de toegang tot het project? Dan tonen de issues die aan dat lid zijn toegewezen geen toewijzing meer. Wordt een team verwijderd? Dan tonen de issues die aan dat team zijn toegewezen geen toewijzing meer. Deze issues verschijnen bij het lezen met --assignee none. Krijgt het lid weer toegang? Dan tonen de issues dat lid weer, tenzij iemand de toewijzing intussen heeft gewijzigd of opgeheven.

​
Zoeken wie eigenaar is van een issue

Het resultaat toont de voorgestelde eigenaren, de beste eerst, en een suggested_assignee. Elke eigenaar heeft een source: inputs telt de paden van stackframes, de modules, de routetemplate, de tags en de regels die LogBrew heeft gecontroleerd. Is de lijst leeg en toont inputs geen paden? Dan heeft het issue geen bewijs om op te matchen. Dat betekent niet dat het issue geen eigenaar heeft. Schrijf eigenaarsregels in een tekstbestand, één regel per tekstregel:
Een patroon path past op het einde van het pad van een stackframe. Zo past src/payments/** op frames onder elke deploymentmap. * past op elke tekst. Eigenaren zijn e-mailadressen van accounts of #team-slug. De laatste regel die past, komt als eerste. Verstuur daarna de regels, een CODEOWNERS-bestand van GitHub, of allebei:
In CODEOWNERS staat een e-mailadres voor een account en @org/team-slug voor het team met die slug. Regels met een account zonder toegang tot het project of met een onbekend team mislukken met 422. Eigenaren in CODEOWNERS die naar niemand verwijzen, verschijnen in unresolved_owners. Een leeg bestand wist de bijbehorende tekst.

​
De geschiedenis van een issue lezen

De geschiedenis toont elke wijziging van status, prioriteit, toewijzing en ernstregel, de nieuwste eerst, met het account dat de wijziging deed. Ze eindigt met first_seen. Van een account dat de toegang tot het project kwijt is, blijft alleen het ID over. Gebruik --limit en de waarden van next_cursor om verder te lezen.

​
Je inbox lezen

De inbox toont de issues die anderen aan jou of aan je teams hebben toegewezen, de nieuwste eerst. unread telt de toewijzingen na je leesmarkering. logbrew inbox read zet de leesmarkering op nu. LogBrew stuurt voor deze toewijzingen geen e-mail. De inbox toont alleen projecten die je nu kunt lezen.

​
Aanbevolen workflow

1

Toon onopgeloste issues binnen één bereik

Gebruik dezelfde filters bij latere lijsten. Een leeg resultaat betekent dat geen issue bij dit bereik past. Het bewijst niet dat het project geen fouten heeft. Kopieer het exacte issue-ID, niet de titel.
2

Lees de details van het issue

Controleer of het teruggegeven project klopt voordat je verdergaat. Leesacties geven een momentopname terug. Lees het issue opnieuw voordat je de status wijzigt.
3

Onderzoek één voorval

De leesacties voor details en onderzoek gebruiken geen lijstfilters. Vergelijk subject.project_id, event.occurred_at, de release en de omgeving met je bereik. Het aanbevolen voorval kan ouder zijn dan het laatste. Volg Een issue onderzoeken voor de volledige beoordeling van het bewijs.
4

Volg tracebewijs alleen als het beschikbaar is

Lees de trace alleen als correlations.trace.status gelijk is aan available. Gebruik het trace-ID uit de response. Verzin er nooit een.
Het lezen van de trace heeft geen tijdfilter. Is de status not_linked? Ga dan verder met het bewijs uit het issue.
5

Verifieer de kandidaatdeployment

Gebruik het onderzochte voorval als basisvoorval. Haal het deployment-ID uit het deploymentbewijs of uit je releaseproces.
Geen herhaling in het waarnemingsvenster bewijst geen blijvende fix. Is status gelijk aan insufficient_traffic of unavailable? Houd het issue dan op unresolved. Volg de teruggegeven volgende stap.
6

Wijzig de status, de prioriteit of de toewijzing

Voer één opdracht uit. Deze opdrachten vragen niet om bevestiging, dus controleer eerst het issue-ID.
Zonder --project accepteert elke opdracht 1 issue-ID. Controleer de exitcode en de teruggegeven status, priority en assignee. Ontbreekt het resultaat? Lees het issue dan opnieuw vóór de volgende wijziging.Oudere scripts kunnen logbrew set issue "<issue_id>" resolved gebruiken, en de verkorte opdrachten resolve, ignore en reopen. ignore zet archived.

​
Veel issues tegelijk wijzigen

Voeg --project toe om met één opdracht tot 100 issues van één project te wijzigen:
De opdracht past één wijziging toe op elk issue. Elk issue-ID mag maar één keer voorkomen. De CLI weigert meer dan 100 ID’s of een herhaald ID voordat er een request wordt verzonden. Het resultaat heeft 1 item per issue, in de volgorde van de opdracht: Elk item heeft issue_id, outcome en issue. issue is het huidige issue, of null bij not_found. Na een netwerkfout kun je dezelfde opdracht opnieuw uitvoeren. Issues die al zijn gewijzigd, tonen dan unchanged. Voer voor meer dan 100 issues meerdere opdrachten uit. Kopieer bij een resultaat not_found het ID opnieuw uit een lijst met issues van dat project. Zie Issues in bulk bijwerken voor het API-request.

​
De volgende status kiezen

  • Laat het op unresolved staan als de fout nog actief is of de fix niet is geverifieerd. Een ontbrekende trace is geen reden om een issue te archiveren.
  • Zet resolved nadat het team het bewijs voor de fix heeft geaccepteerd. Een voorgestelde fix is geen bewijs.
  • Zet archived voor een geaccepteerde situatie of een signaal dat alleen uit tests komt. De beslissing geldt voor elk voorval van het issue. De opdracht heeft geen veld voor een reden, dus noteer de reden in het werkverslag van je team.
  • Heropen met unresolved als er na het oplossen een nieuw voorval binnenkomt. lifecycle.regression.first_reappeared_occurrence identificeert dat voorval. Vergelijk het met het voorval dat voor het oplossen is gebruikt. Maak geen ander issue.

​
Het onderzoek overdragen

Geef de volgende persoon verwijzingen, geen dump van ruwe events:
  • Issue-ID, status, prioriteit, toewijzing en ernst.
  • Project, service, omgeving en release.
  • Tijdstip ‘Eerst gezien’, tijdstip ‘Laatst gezien’ en aantal voorvallen.
  • ID van het gekozen voorval en occurrence_selection.reason.
  • fix.status, cause.status en hun provenance.
  • Tracestatus en trace-ID, als die beschikbaar zijn.
  • Reproductiestatus en ontbrekend bewijs.
  • Resultaat van de verificatie van de kandidaatdeployment.
  • De volgende stap die de response heeft teruggegeven.
Label voorgestelde oorzaken en fixes als voorstellen.

​
Herstellen na CLI-fouten

Controleer de exitcode van het proces voordat je de uitvoer parset. Bij succes gaat de JSON naar standaarduitvoer. Een parseerfout stopt met code 2. Een fout tijdens het uitvoeren stopt met code 1. JSON-fouten gaan naar standaardfout en bevatten ok: false, error, message en next. Toon next als advies. Voer het niet automatisch uit. logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json heeft bijvoorbeeld geen --project. De opdracht stopt met code 2 voordat er een request is verzonden, met de fout invalid_issue_command. Weigert de API een request? Dan is error gelijk aan api_error. Lees status voor de HTTP-status en api_code voor de foutcode van de API. Een mislukte response bewijst niet dat een wijziging van status, prioriteit of toewijzing geen effect had. Lees het issue voordat je het opnieuw probeert.

​
Wat een issue bruikbaar maakt

  • Een duidelijke titel en een leesbaar bericht.
  • Een stabiele vingerafdruk.
  • Stackframes, als die beschikbaar zijn.
  • Context over release, omgeving en service.
  • Tracecontext, als die met het voorval is vastgelegd.
  • Kleine, relevante attributen, geen volledige dumps van payloads.
Zie de referentie van de Telemetrie-API voor lijstfilters en responsecontracten.