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

# Triage en oplossen van issues in LogBrew

> Beheer issues in LogBrew. Lees eerst het bewijs en zoek de eigenaar. Los daarna op, archiveer, heropen, stel prioriteit in of wijs toe aan een persoon of een team.

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](/nl/guides/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:

| Veld | Betekenis |
| - | - |
| `title` | Vastgelegde titel van de fout. |
| `severity` | Vastgelegde ernst. |
| `triage.effective_severity` | Ernst die LogBrew gebruikt na toepassing van issueregels. `severity` behoudt de vastgelegde waarde. `triage.rule_applied` is `true` als er een regel van toepassing is. |
| `occurrence_count` | Aantal bewaarde voorvallen in de groep. |
| `first_seen_at` | Tijdstip van het vroegste bewaarde voorval. |
| `last_seen_at` | Tijdstip van het laatste bewaarde voorval. |
| `project_id` | Project dat het issue bevat. |
| `service_name` | Service van het laatste voorval. |
| `release` | Release van het laatste voorval. |
| `environment` | Omgeving van het laatste voorval. |
| `status` | Workflowstatus van het issue. Zie [Statuswaarden](#status-values). |
| `priority` | Triagevolgorde van het issue. Zie [Prioriteit](#priority). |
| `priority_source` | `manual` als een persoon de prioriteit heeft ingesteld. `derived` als de prioriteit de ernst volgt. |
| `assignee` | Account of team dat verantwoordelijk is voor de volgende stap, of `null`. Zie [Issues toewijzen](#assign-issues). |

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.

## <span id="status-values">Statuswaarden</span>

| Status | Betekenis |
| - | - |
| `unresolved` | Het issue vraagt om een beslissing. |
| `resolved` | Het team heeft het issue als opgelost gemarkeerd. De status bewijst de fix niet. |
| `archived` | Het team heeft het issue uit de actieve triage gehaald. |

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

## <span id="priority">Prioriteit</span>

De prioriteit bepaalt in welke volgorde het team de triage van issues doet:

| Prioriteit | Betekenis |
| - | - |
| `high` | Onderzoek het issue als eerste. |
| `medium` | Onderzoek het issue na de issues met `high`. |
| `low` | Het issue kan wachten. |

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:

```bash theme={null}
logbrew read issues --project "<project_id>" --status unresolved \
  --priority high --since 24h --json
```

## <span id="assign-issues">Issues toewijzen</span>

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.

<Steps>
  <Step title="Zoek op aan wie je kunt toewijzen">
    ```bash theme={null}
    logbrew issues assignees --project "<project_id>" --json
    ```

    `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.
  </Step>

  <Step title="Wijs het issue toe">
    ```bash theme={null}
    logbrew issues assign "<user_id>" "<issue_id>" --json
    logbrew issues assign "team:<team_id>" "<issue_id>" --json
    ```

    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.
  </Step>

  <Step title="Lees je eigen issues">
    ```bash theme={null}
    logbrew read issues --project "<project_id>" --assignee me \
      --status unresolved --json
    ```

    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.
  </Step>
</Steps>

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.

## <span id="find-who-owns-an-issue">Zoeken wie eigenaar is van een issue</span>

```bash theme={null}
logbrew issues owners "<issue_id>" --json
```

Het resultaat toont de voorgestelde eigenaren, de beste eerst, en een
`suggested_assignee`. Elke eigenaar heeft een `source`:

| `source` | Betekenis |
| - | - |
| `ownership_rule` | Een regel van het project past bij het issue. `rule`, `line` en `matched` tonen de regel en waar die op paste. |
| `codeowners` | Een tekstregel uit het CODEOWNERS-bestand van het project past bij het pad van een stackframe. |
| `recent_activity` | Het account heeft het issue gewijzigd of kreeg het toegewezen. |

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

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

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:

```bash theme={null}
logbrew issues ownership set --project "<project_id>" \
  --rules ownership.txt --codeowners .github/CODEOWNERS --json
logbrew issues ownership --project "<project_id>" --json
```

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.

## <span id="read-the-issue-history">De geschiedenis van een issue lezen</span>

```bash theme={null}
logbrew issues activity "<issue_id>" --json
```

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.

## <span id="read-your-inbox">Je inbox lezen</span>

```bash theme={null}
logbrew inbox --json
logbrew inbox read --json
```

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

<Steps>
  <Step title="Toon onopgeloste issues binnen één bereik">
    ```bash theme={null}
    logbrew read issues --project "<project_id>" --environment production \
      --release api@1.2.3 --status unresolved --since 24h --json
    ```

    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.
  </Step>

  <Step title="Lees de details van het issue">
    ```bash theme={null}
    logbrew read issue "<issue_id>" --json
    ```

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

  <Step title="Onderzoek één voorval">
    ```bash theme={null}
    logbrew investigate issue "<issue_id>" --occurrence recommended --json
    ```

    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](/nl/guides/investigate-an-issue) voor
    de volledige beoordeling van het bewijs.
  </Step>

  <Step title="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.

    ```bash theme={null}
    logbrew read trace "<trace_id>" --project "<project_id>" --json
    logbrew read logs --trace "<trace_id>" --project "<project_id>" \
      --since 24h --json
    ```

    Het lezen van de trace heeft geen tijdfilter. Is de status `not_linked`?
    Ga dan verder met het bewijs uit het issue.
  </Step>

  <Step title="Verifieer de kandidaatdeployment">
    Gebruik het onderzochte voorval als basisvoorval. Haal het
    deployment-ID uit het deploymentbewijs of uit je releaseproces.

    ```bash theme={null}
    logbrew investigate issue "<issue_id>" verify \
      --baseline-occurrence "<occurrence_id>" \
      --candidate-deployment "<deployment_id>" \
      --json
    ```

    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.
  </Step>

  <Step title="Wijzig de status, de prioriteit of de toewijzing">
    Voer één opdracht uit. Deze opdrachten vragen niet om bevestiging, dus
    controleer eerst het issue-ID.

    ```bash theme={null}
    logbrew issues resolve "<issue_id>" --json
    logbrew issues archive "<issue_id>" --json
    logbrew issues reopen "<issue_id>" --json
    logbrew issues priority low "<issue_id>" --json
    logbrew issues assign me "<issue_id>" --json
    ```

    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`.
  </Step>
</Steps>

## Veel issues tegelijk wijzigen

Voeg `--project` toe om met één opdracht tot 100 issues van één project te
wijzigen:

```bash theme={null}
logbrew issues archive "<issue_id_1>" "<issue_id_2>" "<issue_id_3>" \
  --project "<project_id>" --json
```

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:

| Uitkomst | Betekenis |
| - | - |
| `updated` | LogBrew heeft de wijziging toegepast. |
| `unchanged` | Het issue had de gevraagde waarde al. |
| `not_found` | Het project heeft geen issue met dit ID. LogBrew heeft er niets aan gewijzigd. |

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](/nl/reference/telemetry-api#update-issues-in-bulk)
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.

| Resultaat | Herstel |
| - | - |
| `not_logged_in` | Vraag een persoon om `logbrew login` uit te voeren en probeer het lezen daarna opnieuw. |
| `invalid_issue_command` | Corrigeer de opdracht. Gebruik `--project` voor meer dan 1 issue, maximaal 100 ID's en elk ID maar één keer. |
| Ongeldig issue-ID | Kopieer het exacte ID uit een lijst met issues of uit een response met details. |
| Issue niet gevonden | Controleer het ingelogde account en het project. |
| Een wijziging mislukt met `status` `403` | Het account kan geen issues beheren in dit project. Vraag iemand met toegang. |
| `invalid_assignee` | De filter `--assignee` accepteert `me`, `none`, `my_teams`, een gebruikers-ID of `team:<team_id>`. |
| Een toewijzing mislukt met `status` `422` en `api_code` `validation_failed` | Het account kan het project niet lezen, of het team hoort niet bij de organisatie van het project. Kies er een uit `logbrew issues assignees`. |
| `invalid_ownership_command`, `invalid_ownership_file` | Corrigeer de opdracht. Een eigenaarsbestand moet UTF-8-tekst zijn van maximaal 128 KiB. |
| `invalid_inbox_command` | Gebruik `logbrew inbox` of `logbrew inbox read`. |
| `investigation_response_invalid` | De response is niet door de validatie van de CLI gekomen. Probeer het één keer opnieuw. Gebeurt het weer? Werk de CLI bij of meld het probleem. Omzeil de validatie niet. |
| Tracestatus `not_linked` | Ga verder met het bewijs uit het issue. Lees geen trace. |
| Tracestatus `unavailable` | Lees het onderzoek later opnieuw. |
| Verificatie `insufficient_traffic` | Houd het issue op `unresolved`. Wacht op verkeer naar de kandidaatrelease en verifieer daarna opnieuw. |

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](/nl/reference/telemetry-api) voor
lijstfilters en responsecontracten.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.