Skip to main content
API Telemetri berupa JSON melalui HTTP di https://api.logbrew.co. SDK publik mengirim batch yang dikelolanya ke POST /v1/events. Klien native kustom mengirim envelope native ke POST /api/telemetry/ingest. Kedua rute ingest memerlukan bearer ingest khusus proyek. Pembacaan dan perubahan milik akun memakai bearer akun. Jangan pernah memakai bearer akun atau sesi browser sebagai konfigurasi SDK atau ingest. Jangan pernah mengirim bearer ingest ke rute baca.

Kirim permintaan dengan lingkup terbatas

Gunakan daftar periksa ini sebelum klien mengirim permintaan:
  1. Pilih rute dan metode HTTP dari tabel endpoint.
  2. Gunakan bearer yang benar: bearer ingest untuk ingest, bearer akun untuk semua hal lain.
  3. Pilih lingkup proyek yang didukung rute. Jangan perluas lingkup setelah respons kosong.
  4. Tambahkan hanya kunci kueri yang diterima rute. Lihat Filter kueri.
  5. Kirim Content-Type: application/json jika rute punya body JSON.
  6. Baca status HTTP dan body respons sebelum Anda mencoba lagi.
  7. Jauhkan bearer, tiket feed, dan body respons lengkap dari log dan prompt agen.

Endpoint

Ingest

Biarkan SDK membuat batch /v1/events. Jangan menyusunnya secara manual. Untuk envelope native, lihat Integrasi SDK.

Pembacaan telemetri

Deployment

Catat deployment dari otomatisasi rilis setelah deployment berhasil atau gagal. Body PUT berisi project_id, release, environment, service_name, status (succeeded atau failed), started_at, finished_at, dan commit_sha yang opsional. Gunakan nilai release, environment, dan service_name yang sama dengan yang dikirim SDK Anda. Akun harus memiliki proyek tersebut. deployment_id adalah ID Anda sendiri untuk deployment. Percobaan ulang dengan ID dan body yang sama mengembalikan deployment yang tersimpan. ID yang sama dengan body berbeda gagal dengan 409 dan idempotency_conflict. Gunakan ID baru untuk deployment yang berbeda.

Investigasi

Setiap rute investigasi mengembalikan paket bukti terbatas untuk satu subjek. Perintah logbrew explain di CLI membaca rute ini dan memvalidasi responsnya.

Analitik produk

Rute analitik POST menerima body JSON, bukan kunci kueri. Lihat Analitik produk.

Feed langsung

Akun dan masuk

Rute penggunaan, kuota, langganan, dan logout ada di API akun.

Kode status sukses

Respons 200 tidak membuktikan bahwa bukti sudah lengkap. Baca kolom cakupan, pemotongan, dan status di respons.

Filter kueri dan paginasi

Setiap rute baca menerima kunci kuerinya sendiri. Alias praktis seperti project, trace, dan user bukan kunci kueri. Secara default, rute daftar mengembalikan array polos, dan mengembalikan envelope kursor dengan pagination=cursor. Daftar deployment selalu mengembalikan objek halaman. Lihat Filter kueri.

Respons dan error

  • Format respons menampilkan satu contoh untuk setiap kelompok respons.
  • Error API mencantumkan kode error dan tindakan pemulihan.
Baca code sebelum pesan untuk manusia. Gunakan next_action untuk perilaku program dan next untuk panduan bagi manusia. Jangan mem-parse kata-kata di error atau next.

Perbarui masalah

Permintaan ini memakai bearer akun. Bearer ini sengaja dibedakan dari LOGBREW_INGEST_BEARER. Akun harus punya izin untuk mengelola masalah di proyek tempat masalah itu berada. Jika tidak, permintaan gagal dengan 403 dan forbidden. Izin yang sama mencakup perubahan status, prioritas, dan penanggung jawab, serta aturan masalah dan log. Setiap permintaan mengisi 1 atau lebih kolom berikut: Permintaan tanpa satu pun kolom ini gagal dengan 422 dan validation_failed. Masalah punya 0 atau 1 penanggung jawab: satu akun atau satu tim. Akun harus bisa membaca proyek, dan tim harus berada di organisasi proyek. Jika tidak, permintaan gagal dengan 422 dan validation_failed, dan LogBrew tidak mengubah apa pun. Ambil daftar akun yang bisa Anda tugaskan dari Tampilkan daftar penanggung jawab. Nilai assignee lain juga gagal dengan 422 dan validation_failed. Prioritas yang Anda tetapkan akan tetap seperti itu. Tanpa prioritas yang Anda tetapkan, prioritas mengikuti tingkat keparahan masalah: error dan critical menjadi high, warning menjadi medium, dan info menjadi low. Kolom yang sudah berisi nilai yang diminta tidak berubah. Anda bisa mengirim permintaan yang sama lagi setelah timeout. Timeout tidak membuktikan bahwa perubahan tidak terjadi. Baca masalah lagi sebelum Anda mengirim perubahan yang berbeda.

Perbarui satu masalah

Tambahkan response_version=4 agar respons berisi archived, prioritas, dan penanggung jawab. Di versi 4, assignee bernilai { "type": "user", "user_id", "name", "email" }, { "type": "team", "team_id", "slug", "name" }, atau null. Versi 3 menampilkan penanggung jawab berupa tim sebagai null.
Responsnya berupa masalah yang sudah diperbarui. Lihat contoh respons status masalah.

Perbarui masalah secara massal

Kirim project_id dan 1 sampai 100 ID masalah yang berbeda dari proyek itu:
Permintaan ini menerapkan perubahan yang sama ke setiap masalah. Respons berisi project_id dan results, dengan 1 hasil untuk setiap ID masalah, sesuai urutan di permintaan. Setiap hasil berisi issue_id, outcome, dan issue. issue adalah masalah terkini dalam versi respons 3, atau null untuk not_found. Tambahkan "response_version": 2 ke body agar setiap masalah dikembalikan dalam versi respons 4. Daftar kosong, lebih dari 100 ID, atau ID yang berulang gagal dengan 422 dan validation_failed. Pecah kumpulan yang lebih besar menjadi beberapa permintaan. Jika akun tidak bisa membaca proyek, permintaan gagal dengan 404 dan not_found.

Tampilkan daftar penanggung jawab

Kirim ID proyek untuk mendapatkan setiap akun yang bisa ditugaskan masalah di proyek itu:
Daftar ini berisi setiap akun yang bisa membaca proyek. Setiap entri berisi user_id, name, dan email. name bernilai null jika akun tidak punya nama. Tambahkan response_version=2 untuk juga mendapatkan teams: setiap tim di organisasi proyek, dengan team_id, slug, dan name. Lihat respons daftar penanggung jawab. Setiap akun yang bisa membaca proyek bisa mengambil daftar ini. Jika akun tidak bisa membaca proyek, permintaan gagal dengan 404 dan not_found. Saat anggota kehilangan akses ke proyek, masalah yang ditugaskan ke anggota itu tidak menampilkan penanggung jawab. Jika anggota itu mendapatkan akses lagi, masalah itu kembali menampilkan anggota tersebut, kecuali seseorang sudah mengubah atau menghapus penanggung jawabnya sementara itu.

Kepemilikan dan usulan pemilik

GET /api/telemetry/issues/ownership?project_id=<project-uuid> mengembalikan rules, codeowners, updated_at, dan unresolved_owners. Setiap akun yang bisa membaca proyek bisa membacanya. PUT dengan project_id serta rules, codeowners, atau keduanya mengganti teks tersebut dan butuh izin untuk mengelola masalah. Kolom yang tidak Anda kirim tetap menyimpan teksnya, dan string kosong menghapusnya. Setiap teks berukuran maksimal 128 KiB. Teks yang tidak valid gagal dengan 422 dan menyebutkan barisnya. GET /api/telemetry/issues/{issue_id}/owners?response_version=2 mengembalikan suggested_assignee, owners, dan inputs. Setiap pemilik punya type (user atau team), source (ownership_rule, codeowners, atau recent_activity), rule, line, dan matched. Versi 1, yaitu default, hanya menampilkan akun.

Riwayat masalah

GET /api/telemetry/issues/{issue_id}/activity?response_version=2 mengembalikan activity, mulai dari yang terbaru, dan next_cursor. Setiap entri punya type (status, priority, assigned, unassigned, severity_rule, atau first_seen), value, actor_id, actor, assignee_id, assignee, team, dan at. limit bernilai 1 sampai 200, dengan default 50. Kirim cursor_time dan cursor_id dari next_cursor untuk halaman berikutnya.

Notifikasi

GET /api/telemetry/issues/notifications mengembalikan notifications, unread, read_at, dan next_cursor. Setiap notifikasi adalah penugasan masalah kepada Anda atau tim Anda oleh akun lain. POST /api/telemetry/issues/notifications/read dengan objek JSON kosong, atau dengan read_at, memindahkan penanda baca Anda. Penanda ini tidak pernah mundur.

Tetapkan aturan masalah dan log

Aturan mengubah cara LogBrew menampilkan sinyal yang cocok. Aturan tidak menghapus data. severity yang terekam tetap sama, dan respons menampilkan aturan di triage. severity berisi info, warning, error, critical, atau source. source menghapus tingkat keparahan pengganti dan kembali menampilkan tingkat keparahan yang terekam. Untuk aturan log, ignored: true menyembunyikan log yang cocok dari daftar log default. Baca log itu dengan status=ignored atau status=all. Aturan berlaku untuk sinyal cocok yang tersimpan dan yang akan datang. Nilai lain gagal dengan 422 dan validation_failed.
Jangan kirim rilis kosong. LogBrew menolaknya agar pelacakan rilis tetap tepercaya.