Skip to main content
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 dan jalankan logbrew login sebelum mulai.

​
Masalah dan kemunculan

Daftar masalah mengembalikan ringkasan kelompok, bukan peristiwa lengkap. Baca kolom berikut sebelum Anda membuka detailnya: 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.

​
Nilai status

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.

​
Prioritas

Prioritas menentukan urutan triase masalah oleh tim: 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:

​
Tugaskan masalah

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

Cari siapa yang bisa ditugaskan

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

Tugaskan masalah

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

Baca masalah Anda

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

​
Cari pemilik masalah

Hasilnya berisi daftar usulan pemilik, mulai dari yang paling cocok, dan satu suggested_assignee. Setiap pemilik punya source: 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:
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:
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.

​
Baca riwayat masalah

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.

​
Baca kotak masuk Anda

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

1

Tampilkan masalah yang belum selesai dalam satu lingkup

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

Baca detail masalah

Pastikan proyek yang dikembalikan sudah benar sebelum Anda melanjutkan. Pembacaan mengembalikan snapshot. Baca lagi masalah itu sebelum Anda mengubah status.
3

Investigasi satu kemunculan

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 untuk peninjauan bukti lengkap.
4

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.
Pembacaan trace tidak punya filter waktu. Jika statusnya not_linked, lanjutkan dengan bukti masalah.
5

Verifikasi deployment kandidat

Gunakan kemunculan yang diinvestigasi sebagai acuan. Ambil ID deployment dari bukti deployment atau proses rilis Anda.
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.
6

Ubah status, prioritas, atau penanggung jawab

Jalankan satu perintah. Perintah ini tidak meminta konfirmasi, jadi periksa ID masalah terlebih dahulu.
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.

​
Ubah banyak masalah sekaligus

Tambahkan --project untuk mengubah hingga 100 masalah dari satu proyek dalam satu perintah:
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: 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 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. 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 untuk filter daftar dan kontrak respons.