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

# Triase dan penyelesaian masalah di LogBrew

> Kelola masalah di LogBrew. Baca bukti kemunculan, cari pemiliknya, lalu selesaikan, arsipkan, buka kembali, beri prioritas, atau tugaskan masalah ke seseorang atau ke tim.

Masalah mengelompokkan kemunculan error yang punya fingerprint yang sama. Baca
ringkasan kelompok dan satu kemunculan sebelum Anda mengubah status,
prioritas, atau penanggung jawab. Perubahan status, prioritas, atau penanggung
jawab mencatat keputusan tim. Perubahan itu tidak memperbaiki perangkat lunak
atau menulis ulang peristiwa yang terekam.

Instal [LogBrew CLI](/id/guides/cli) dan jalankan `logbrew login` sebelum mulai.

## Masalah dan kemunculan

Daftar masalah mengembalikan ringkasan kelompok, bukan peristiwa lengkap. Baca
kolom berikut sebelum Anda membuka detailnya:

| Kolom | Arti |
| - | - |
| `title` | Judul kegagalan yang terekam. |
| `severity` | Tingkat keparahan yang terekam. |
| `triage.effective_severity` | Tingkat keparahan yang dipakai LogBrew setelah aturan masalah. `severity` tetap menyimpan nilai yang terekam. `triage.rule_applied` bernilai `true` jika sebuah aturan berlaku. |
| `occurrence_count` | Jumlah kemunculan yang tersimpan dalam kelompok. |
| `first_seen_at` | Waktu kemunculan tersimpan yang paling awal. |
| `last_seen_at` | Waktu kemunculan tersimpan yang paling akhir. |
| `project_id` | Proyek yang berisi masalah. |
| `service_name` | Layanan dari kemunculan terbaru. |
| `release` | Rilis dari kemunculan terbaru. |
| `environment` | Lingkungan dari kemunculan terbaru. |
| `status` | Status alur kerja masalah. Lihat [Nilai status](#status-values). |
| `priority` | Urutan triase masalah. Lihat [Prioritas](#priority). |
| `priority_source` | `manual` jika seseorang menetapkan prioritas. `derived` jika prioritas mengikuti tingkat keparahan. |
| `assignee` | Akun atau tim yang memegang langkah berikutnya, atau `null`. Lihat [Tugaskan masalah](#assign-issues). |

Jumlah kemunculan bukan jumlah pengguna yang terdampak. Jumlah dan waktu
berlaku untuk lingkup yang dikembalikan, bukan untuk seluruh riwayat error.
Filter `--since` atau `--until` membatasi kemunculan yang dihitung LogBrew.
Saat Anda melaporkan suatu jumlah, laporkan juga filter yang menghasilkannya.

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

| Status | Arti |
| - | - |
| `unresolved` | Masalah butuh keputusan. |
| `resolved` | Tim menandai masalah sebagai sudah diperbaiki. Status ini tidak membuktikan perbaikannya. |
| `archived` | Tim mengeluarkan masalah dari triase aktif. |

`archived` sebelumnya bernama `ignored`. Kedua nama memilih masalah yang sama,
dan keduanya diterima sebagai input. `logbrew read`, `logbrew issues`, dan API
versi 2 dan 3 menampilkan `archived`. API versi 1 (default), stream pantauan
langsung, dan respons investigasi masalah menampilkan `ignored`. Dasbor
menampilkan status ini sebagai Belum selesai, Selesai, dan Diarsipkan.

Status berlaku untuk seluruh masalah, bukan untuk satu kemunculan. Tingkat
keparahan menunjukkan urgensi, dan status mencatat keputusan. Pisahkan
keduanya. Masalah `critical` bisa menjadi `resolved` setelah perbaikan yang
terverifikasi. Masalah `archived` tetap menyimpan tingkat keparahan yang
terekam.

LogBrew tidak membuka kembali masalah yang sudah selesai secara otomatis. Saat
kemunculan baru datang setelah masalah diselesaikan, investigasi melaporkan
`lifecycle.effective_status` sebagai `regressed`. `status` tetap `resolved`
sampai seseorang membuka kembali masalah itu.

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

Prioritas menentukan urutan triase masalah oleh tim:

| Prioritas | Arti |
| - | - |
| `high` | Periksa masalah ini lebih dulu. |
| `medium` | Periksa masalah ini setelah masalah `high`. |
| `low` | Masalah ini bisa menunggu. |

Setiap masalah punya prioritas. Jika tidak ada yang menetapkannya, prioritas
mengikuti tingkat keparahan masalah: `error` dan `critical` menjadi `high`,
`warning` menjadi `medium`, dan `info` menjadi `low`. Jika aturan masalah
mengubah tingkat keparahan, prioritas mengikuti `triage.effective_severity`.
Dalam hal itu, `priority_source` bernilai `derived`. Jika seseorang menetapkan
prioritas, prioritas itu tetap dan `priority_source` bernilai `manual`.

Untuk menampilkan masalah yang perlu diperiksa lebih dulu:

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

## <span id="assign-issues">Tugaskan masalah</span>

Tugaskan masalah untuk menunjukkan siapa yang memegang langkah berikutnya.
Masalah punya 0 atau 1 penanggung jawab: satu akun atau satu tim.

<Steps>
  <Step title="Cari siapa yang bisa ditugaskan">
    ```bash theme={null}
    logbrew issues assignees --project "<project_id>" --json
    ```

    `assignees` berisi setiap akun yang bisa membaca proyek, dengan `user_id`,
    `name`, dan `email`. `teams` berisi setiap tim di organisasi proyek, dengan
    `team_id`, `slug`, dan `name`. Anda tidak bisa menugaskan akun yang tidak
    bisa membaca proyek, atau tim dari organisasi lain.
  </Step>

  <Step title="Tugaskan masalah">
    ```bash theme={null}
    logbrew issues assign "<user_id>" "<issue_id>" --json
    logbrew issues assign "team:<team_id>" "<issue_id>" --json
    ```

    Gunakan `me` sebagai pengganti ID pengguna untuk menugaskan masalah ke
    diri Anda sendiri. Gunakan `logbrew issues unassign "<issue_id>" --json`
    untuk menghapus penanggung jawab. Tambahkan `--project` untuk mengubah
    hingga 100 masalah dari satu proyek.
  </Step>

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

    Gunakan `--assignee my_teams` untuk masalah milik tim Anda,
    `--assignee "team:<team_id>"` untuk satu tim, dan `--assignee none` untuk
    masalah yang belum punya penanggung jawab.
  </Step>
</Steps>

Untuk menugaskan masalah, Anda butuh izin untuk mengelola masalah di proyek.
Izin yang sama memungkinkan Anda mengubah status, prioritas, aturan
kepemilikan, serta aturan masalah dan log. Pemilik dan admin organisasi
membuat tim dan memilih anggotanya. Tim tidak memberi anggotanya akses ke
proyek.

Jika seorang anggota kehilangan akses ke proyek, masalah yang ditugaskan
kepadanya tidak menampilkan penanggung jawab. Jika sebuah tim dihapus, masalah
yang ditugaskan ke tim itu juga tidak menampilkan penanggung jawab. Masalah ini
muncul dalam pembacaan `--assignee none`. Jika anggota itu mendapat akses
lagi, masalah tersebut kembali menampilkan anggota itu, kecuali seseorang
sudah mengubah atau menghapus penanggung jawabnya.

## <span id="find-who-owns-an-issue">Cari pemilik masalah</span>

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

Hasilnya berisi daftar usulan pemilik, mulai dari yang paling cocok, dan satu
`suggested_assignee`. Setiap pemilik punya `source`:

| `source` | Arti |
| - | - |
| `ownership_rule` | Salah satu aturan proyek cocok dengan masalah. `rule`, `line`, dan `matched` menunjukkan aturannya dan bagian yang cocok. |
| `codeowners` | Satu baris di file CODEOWNERS proyek cocok dengan path stack frame. |
| `recent_activity` | Akun itu pernah mengubah masalah atau pernah ditugaskan ke masalah itu. |

`inputs` menghitung path stack frame, modul, template rute, tag, dan aturan
yang diperiksa LogBrew. Jika daftarnya kosong dan `inputs` tidak berisi path,
artinya masalah belum punya bukti untuk dicocokkan, bukan berarti tidak ada
pemiliknya.

Tulis aturan kepemilikan di file teks, satu aturan per baris:

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

Pola `path` mencocokkan bagian akhir path stack frame, jadi `src/payments/**`
cocok dengan frame di bawah direktori deployment mana pun. `*` cocok dengan
teks apa pun. Pemilik berupa email akun atau `#team-slug`. Aturan cocok yang
paling akhir didahulukan. Lalu kirim aturannya, file CODEOWNERS dari GitHub,
atau keduanya:

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

Di CODEOWNERS, email menunjuk ke satu akun, dan `@org/team-slug` menunjuk ke
tim dengan slug itu. Aturan yang menyebut akun tanpa akses ke proyek atau tim
yang tidak dikenal gagal dengan `422`. Pemilik di CODEOWNERS yang tidak
menunjuk ke siapa pun muncul di `unresolved_owners`. File kosong menghapus
isinya.

## <span id="read-the-issue-history">Baca riwayat masalah</span>

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

Riwayat menampilkan setiap perubahan status, prioritas, penanggung jawab, dan
aturan tingkat keparahan, mulai dari yang terbaru, beserta akun yang
membuatnya. Riwayat diakhiri dengan `first_seen`. Untuk akun yang sudah
kehilangan akses ke proyek, hanya ID-nya yang tersisa. Gunakan `--limit` dan
nilai `next_cursor` untuk membaca entri berikutnya.

## <span id="read-your-inbox">Baca kotak masuk Anda</span>

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

Kotak masuk menampilkan masalah yang ditugaskan orang lain kepada Anda atau
ke tim Anda, mulai dari yang terbaru. `unread` menghitung penugasan setelah
penanda baca Anda. `logbrew inbox read` memindahkan penanda baca ke waktu
sekarang. LogBrew tidak mengirim email untuk penugasan ini. Kotak masuk hanya
menampilkan proyek yang bisa Anda baca saat ini.

## Alur kerja yang disarankan

<Steps>
  <Step title="Tampilkan masalah yang belum selesai dalam satu lingkup">
    ```bash theme={null}
    logbrew read issues --project "<project_id>" --environment production \
      --release api@1.2.3 --status unresolved --since 24h --json
    ```

    Pertahankan filter yang sama pada pembacaan daftar berikutnya. Hasil
    kosong berarti tidak ada masalah yang cocok dengan lingkup ini. Hasil
    kosong tidak membuktikan bahwa proyek tidak punya error. Salin ID masalah
    yang tepat, bukan judulnya.
  </Step>

  <Step title="Baca detail masalah">
    ```bash theme={null}
    logbrew read issue "<issue_id>" --json
    ```

    Pastikan proyek yang dikembalikan sudah benar sebelum Anda melanjutkan.
    Pembacaan mengembalikan snapshot. Baca lagi masalah itu sebelum Anda
    mengubah status.
  </Step>

  <Step title="Investigasi satu kemunculan">
    ```bash theme={null}
    logbrew investigate issue "<issue_id>" --occurrence recommended --json
    ```

    Pembacaan detail dan investigasi tidak memakai filter daftar. Bandingkan
    `subject.project_id`, `event.occurred_at`, rilis, dan lingkungan dengan
    lingkup Anda. Kemunculan yang direkomendasikan bisa lebih lama dari
    kemunculan terbaru. Ikuti [Investigasi masalah](/id/guides/investigate-an-issue)
    untuk peninjauan bukti lengkap.
  </Step>

  <Step title="Ikuti bukti trace hanya jika tersedia">
    Baca trace hanya jika `correlations.trace.status` bernilai `available`.
    Gunakan ID trace dari respons. Jangan pernah mengarang ID trace.

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

    Pembacaan trace tidak punya filter waktu. Jika statusnya `not_linked`,
    lanjutkan dengan bukti masalah.
  </Step>

  <Step title="Verifikasi deployment kandidat">
    Gunakan kemunculan yang diinvestigasi sebagai acuan. Ambil ID deployment
    dari bukti deployment atau proses rilis Anda.

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

    Tidak adanya kemunculan ulang dalam rentang waktu pengamatan tidak membuktikan
    perbaikan permanen. Jika `status` bernilai `insufficient_traffic` atau
    `unavailable`, biarkan masalah tetap `unresolved`. Ikuti tindakan
    berikutnya yang dikembalikan.
  </Step>

  <Step title="Ubah status, prioritas, atau penanggung jawab">
    Jalankan satu perintah. Perintah ini tidak meminta konfirmasi, jadi
    periksa ID masalah terlebih dahulu.

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

    Tanpa `--project`, setiap perintah menerima 1 ID masalah. Periksa kode
    keluar serta `status`, `priority`, dan `assignee` yang dikembalikan. Jika
    hasilnya tidak ada, baca lagi masalah itu sebelum perubahan berikutnya.

    Skrip lama dapat memakai `logbrew set issue "<issue_id>" resolved` serta
    pintasan `resolve`, `ignore`, dan `reopen`. `ignore` menetapkan
    `archived`.
  </Step>
</Steps>

## Ubah banyak masalah sekaligus

Tambahkan `--project` untuk mengubah hingga 100 masalah dari satu proyek dalam
satu perintah:

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

Perintah ini menerapkan satu perubahan ke setiap masalah. Setiap ID masalah
hanya boleh muncul sekali. CLI menolak lebih dari 100 ID atau ID yang berulang
sebelum mengirim permintaan. Hasilnya punya 1 entri untuk setiap masalah,
sesuai urutan di perintah:

| Hasil | Arti |
| - | - |
| `updated` | LogBrew menerapkan perubahan. |
| `unchanged` | Masalah sudah punya nilai yang diminta. |
| `not_found` | Proyek tidak punya masalah dengan ID ini. LogBrew tidak mengubah apa pun untuknya. |

Setiap entri punya `issue_id`, `outcome`, dan `issue`. `issue` adalah masalah
saat ini, atau `null` untuk `not_found`. Anda dapat menjalankan perintah yang
sama lagi setelah kegagalan jaringan. Masalah yang sudah berubah akan
menampilkan `unchanged`. Untuk lebih dari 100 masalah, jalankan beberapa
perintah. Untuk hasil `not_found`, salin lagi ID dari daftar masalah proyek
itu. Lihat
[Perbarui masalah secara massal](/id/reference/telemetry-api#update-issues-in-bulk)
untuk permintaan API-nya.

## Pilih status berikutnya

* **Biarkan `unresolved`** jika kegagalan masih aktif atau perbaikannya belum
  terverifikasi. Trace yang tidak terekam bukan alasan untuk mengarsipkan
  masalah.
* **Tetapkan `resolved`** setelah tim menerima bukti perbaikan. Usulan
  perbaikan bukan bukti.
* **Tetapkan `archived`** untuk kondisi yang diterima atau sinyal yang hanya
  untuk pengujian. Keputusan ini berlaku untuk setiap kemunculan masalah.
  Perintahnya tidak punya kolom alasan, jadi catat alasannya di catatan kerja
  tim Anda.
* **Buka kembali dengan `unresolved`** jika kemunculan baru datang setelah
  masalah diselesaikan. `lifecycle.regression.first_reappeared_occurrence`
  mengidentifikasi kemunculan itu. Bandingkan dengan kemunculan yang dipakai
  saat penyelesaian. Jangan membuat masalah lain.

## Serahkan investigasi

Beri orang berikutnya referensi, bukan dump peristiwa mentah:

* ID masalah, status, prioritas, penanggung jawab, dan tingkat keparahan.
* Proyek, layanan, lingkungan, dan rilis.
* Waktu pertama terlihat, waktu terakhir terlihat, dan jumlah kemunculan.
* ID kemunculan yang dipilih dan `occurrence_selection.reason`.
* `fix.status`, `cause.status`, dan `provenance` keduanya.
* Status trace dan ID trace, jika tersedia.
* Status reproduksi dan bukti yang tidak terekam.
* Hasil verifikasi deployment kandidat.
* Tindakan berikutnya yang dikembalikan respons.

Beri label usulan pada penyebab dan perbaikan yang diusulkan.

## Pulihkan dari error CLI

Periksa kode keluar proses sebelum Anda mem-parse output. Jika berhasil, JSON
ditulis ke standard output. Error parsing keluar dengan kode `2`. Error
runtime keluar dengan kode `1`. Error JSON ditulis ke standard error dan berisi
`ok: false`, `error`, `message`, dan `next`. Tampilkan `next` sebagai panduan.
Jangan jalankan secara otomatis.

Misalnya, `logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json`
tidak punya `--project`. Perintah ini keluar dengan kode `2` sebelum
permintaan dikirim, dengan error `invalid_issue_command`.

Jika API menolak permintaan, `error` bernilai `api_error`. Baca `status` untuk
status HTTP dan `api_code` untuk kode error API.

| Hasil | Pemulihan |
| - | - |
| `not_logged_in` | Minta seseorang menjalankan `logbrew login`, lalu coba lagi pembacaannya. |
| `invalid_issue_command` | Perbaiki perintah. Gunakan `--project` untuk lebih dari 1 masalah, maksimal 100 ID, dan setiap ID sekali. |
| ID masalah tidak valid | Salin ID yang tepat dari daftar masalah atau respons detail. |
| Masalah tidak ditemukan | Pastikan akun yang sedang masuk dan proyeknya sudah benar. |
| Perubahan gagal dengan `status` `403` | Akun tidak bisa mengelola masalah di proyek ini. Minta bantuan seseorang yang punya akses. |
| `invalid_assignee` | Filter `--assignee` menerima `me`, `none`, `my_teams`, ID pengguna, atau `team:<team_id>`. |
| Penugasan gagal dengan `status` `422` dan `api_code` `validation_failed` | Akun tidak bisa membaca proyek, atau tim tidak ada di organisasi proyek. Pilih salah satu dari `logbrew issues assignees`. |
| `invalid_ownership_command`, `invalid_ownership_file` | Perbaiki perintah. File kepemilikan harus berupa teks UTF-8 dengan ukuran maksimal 128 KiB. |
| `invalid_inbox_command` | Gunakan `logbrew inbox` atau `logbrew inbox read`. |
| `investigation_response_invalid` | Respons gagal validasi CLI. Coba lagi sekali. Jika terulang, perbarui CLI atau laporkan masalah. Jangan melewati validasi. |
| Status trace `not_linked` | Lanjutkan dengan bukti masalah. Jangan membaca trace. |
| Status trace `unavailable` | Coba lagi pembacaan investigasi nanti. |
| Verifikasi `insufficient_traffic` | Biarkan masalah tetap `unresolved`. Tunggu traffic pada rilis kandidat, lalu verifikasi lagi. |

Respons yang gagal tidak membuktikan bahwa perubahan status, prioritas, atau
penanggung jawab tidak berdampak. Baca masalah itu sebelum Anda mencoba lagi.

## Ciri masalah yang berguna

* Judul yang jelas dan pesan yang mudah dibaca.
* Fingerprint yang stabil.
* Stack frame, jika tersedia.
* Konteks rilis, lingkungan, dan layanan.
* Konteks trace, jika direkam bersama kemunculan.
* Atribut kecil yang relevan, bukan dump payload lengkap.

Lihat referensi [API Telemetri](/id/reference/telemetry-api) untuk filter
daftar dan kontrak respons.


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