Skip to main content
Halaman ini memberi satu contoh untuk setiap jenis respons API Telemetri. Semua nilai adalah contoh sintetis. Untuk kode error dan cara pemulihannya, lihat Error API.

Baca respons

Baca setiap respons dengan urutan ini:
  1. Baca status HTTP.
  2. Pastikan body punya bentuk yang sesuai dengan rutenya.
  3. Pastikan setiap project_id ada di dalam lingkup proyek yang diminta.
  4. Biarkan nilai enum kanonis dan ID tetap seperti aslinya.
  5. Ikuti next_action hanya jika klien mendukung code dan target-nya.
  6. Perlakukan null, kolom yang tidak disertakan, dan daftar kosong sebagai status yang berbeda.
200 OK bisa berisi daftar kosong. Daftar log yang kosong berarti tidak ada log yang cocok dengan permintaan. Itu tidak berarti masalah, trace, atau aksi juga kosong. Jangan gabungkan sinyal hanya karena stempel waktunya berdekatan. Ikuti trace hanya jika respons berisi trace_id-nya yang persis. 404 dan daftar kosong adalah dua hasil yang berbeda. Rute daftar mengembalikan [] jika tidak ada record yang cocok. Rute detail mengembalikan 404 dengan code: not_found jika tidak menemukan record yang bisa dibaca. Kedua hasil itu tidak membuktikan bahwa ingest gagal.

Data yang perlu dikirim

Kegunaan respons bergantung pada telemetri yang Anda kirim. Kirim nilai berikut di setiap envelope atau penyiapan SDK:
  • release dan environment.
  • Nama yang stabil untuk layanan, aksi, dan metrik.
  • Konteks trace jika log, span, aksi, dan masalah berasal dari permintaan yang sama.
  • Nilai tingkat keparahan kanonis: info, warning, error, dan critical.
  • Atribut yang membantu debugging, tanpa rahasia atau data pribadi yang tidak perlu.
Lihat Integrasi SDK dan Kendalikan data yang direkam.

Respons ingest

SDK publik membaca respons POST /v1/events untuk Anda. Kode aplikasi tidak perlu menanganinya.

Respons batch SDK

Batch SDK yang berhasil mengembalikan 200 OK beserta jumlah yang diterima untuk setiap stream:
Jumlah ini hanya mencakup batch ini. Percobaan ulang untuk batch yang sudah diterima LogBrew mengembalikan 0 untuk setiap stream, dan jumlah peristiwanya ada di already_accepted. Pertahankan ID peristiwa asli saat Anda mencoba lagi.

Respons envelope native

POST /api/telemetry/ingest mengembalikan 200 OK beserta jumlah item yang diterima untuk setiap stream:
Respons native tidak punya kolom metrics atau context_updated. Jangan tambahkan kolom itu. already_accepted menghitung item yang id-nya sudah diterima LogBrew sebelumnya untuk proyek itu. Lihat envelope native langsung.

Error ingest

401 dengan code: ingest_key_invalid berarti bearer ingest sudah dicabut, kedaluwarsa, atau tidak valid untuk proyek itu. Di POST /v1/events, permintaan tanpa bearer atau dengan bearer yang bukan kunci ingest mengembalikan 401 dengan code: unauthorized. Gunakan bearer ingest khusus proyek yang berlaku saat ini. Jangan mencoba lagi dengan bearer akun. Batch SDK yang ditolak mengembalikan 422 dengan code: validation_failed:
Nilai error lain antara lain SDK event batch requires at least one event dan SDK event type is not supported by this ingest route. Periksa versi SDK dan konfigurasi transport. Jangan kirim batch kosong. Jangan ubah tipe peristiwa atau ID hanya agar batch lolos validasi. Permintaan dengan metode selain POST mengembalikan 405 dengan code: method_not_allowed. Body JSON yang tidak bisa dibaca mengembalikan code: invalid_json.

Format respons daftar telemetri

Secara default, rute daftar mengembalikan array JSON polos. Daftar kosong yang berhasil adalah []. Dengan pagination=cursor, rute mengembalikan envelope. Kunci koleksinya sesuai dengan sinyal: next_cursor adalah objek berisi kolom lanjutan, atau null di halaman terakhir. Baris diurutkan dari yang terbaru. Lihat paginasi berbasis kursor.

Respons log

Halaman kursor berisi log dengan limit=1:
Log berisi level untuk kompatibilitas dan severity untuk tampilan. Keduanya menyimpan nilai kanonis. triage menyimpan hasil aturan tingkat keparahan. Lihat respons aturan tingkat keparahan. trace_id dan span_id bernilai null jika log tidak punya tautan trace. Dalam kasus itu, next_action adalah inspect_related_logs dengan target telemetry_logs. Log, masalah, dan aksi memakai 2 pasangan next_action yang sama. GET /api/logs/{log_id} mengembalikan satu log dengan bentuk yang sama.

Respons masalah

GET /api/telemetry/issues/{issue_id} mengembalikan satu masalah terkelompok. Daftarnya mengembalikan objek yang sama. Contoh ini memakai versi respons default, yaitu versi 1:
Di versi 1, status bernilai unresolved, resolved, atau ignored. Untuk masalah yang diarsipkan, triage.ignored bernilai true. Untuk pasangan next_action dan pembacaan yang mengikutinya, lihat Investigasi masalah. first_seen_at dan last_seen_at adalah waktu kemunculan pertama dan kemunculan terbaru. Keduanya tidak berubah saat status berubah. Beberapa kolom hanya muncul jika LogBrew punya datanya: symbolication.status bernilai resolved, invalid_metadata, artifact_not_found, source_not_resolved, atau unavailable. Daftar, perubahan status, dan perubahan aturan tidak mengembalikan symbolication. Dengan response_version=2, masalah punya kolom yang sama, dengan perubahan berikut:
Contoh ini hanya menampilkan sebagian kolom. Prioritas turunan bernilai high untuk error dan critical, medium untuk warning, dan low untuk info. Prioritas ini memakai triage.effective_severity, jadi aturan tingkat keparahan masalah bisa mengubahnya. Dengan response_version=3, masalah punya semua kolom versi 2 ditambah assignee. assignee bernilai null jika masalah belum punya penanggung jawab:
Masalah tidak menampilkan penanggung jawab jika anggota yang ditugaskan tidak bisa membaca proyek itu lagi. Dengan response_version=4, assignee juga punya type. Penanggung jawab user punya user_id, name, dan email, seperti di versi 3. Penanggung jawab team punya team_id, slug, dan name. Versi 3 menampilkan tim penanggung jawab sebagai null. CLI meminta versi 4:
response_version lain mengembalikan 422 dengan code: validation_failed. Halaman kursor memakai versi yang sama untuk setiap masalah di issues.

Respons daftar penanggung jawab

GET /api/telemetry/issues/assignees?project_id=<project_id> mengembalikan setiap akun yang bisa ditugaskan masalah di proyek itu:
Tambahkan response_version=2 untuk juga mendapatkan teams: setiap tim di organisasi proyek, dengan team_id, slug, dan name. Jika akun tidak bisa membaca proyek itu, rute mengembalikan 404 dengan code: not_found.

Respons aksi

distinct_id mengikuti satu pelaku atau sesi. Perlakukan distinct_id dan session_id sebagai ID buram: jangan mengurai atau menafsirkan isinya. session_id dan trace_id bernilai null jika tidak terekam. span_id tidak disertakan jika tidak terekam. Aksi tidak punya tingkat keparahan. Lihat Perekaman peristiwa produk.

Respons metrik

Setiap item adalah satu sampel. Jangan pakai jumlah sampel sebagai jumlah peristiwa atau jumlah pengguna. unit, temporality, trace_id, dan span_id bernilai null jika tidak terekam. Nilai null bukan nol.

Respons rilis

Satu baris mencakup satu proyek, rilis, lingkungan, dan layanan. Jumlah di dalamnya hanya menggambarkan baris itu. trace_health.status bernilai unknown jika baris tidak punya trace, no_errors_observed, atau errors_observed. error_rate_basis_points adalah porsi trace yang punya span error, dari 0 sampai 10000. Nilai ini bukan tingkat error untuk semua permintaan. next_action menunjuk ke tipe sinyal pertama yang punya data, dengan urutan ini: Lihat Rilis.

Respons pencarian trace

GET /api/telemetry/traces?pagination=cursor mengembalikan satu baris untuk setiap trace, ditambah catatan naming_quality untuk halaman yang dikembalikan:
naming_quality hanya mencakup halaman yang dikembalikan. Nilai ini bukan skor untuk seluruh akun. truncated: true berarti masih ada halaman lain. Jika halaman itu punya nama generik, rute yang tidak cocok, atau operasi generik, next_action adalah improve_trace_naming dengan target sdk_configuration. Tanpa pagination=cursor, rute mengembalikan array trace polos tanpa naming_quality. next_cursor berisi time dan trace_id. Kirim keduanya sebagai cursor_time dan cursor_trace_id. GET /api/telemetry/traces/{trace_id} mengembalikan span dari satu trace. GET /api/telemetry/traces/{trace_id}/summary mengembalikan root span, span error, layanan, durasi, dan jalur paling lambat tanpa atribut span mentah. 404 dari ringkasan berarti tidak ada trace yang cocok dengan lingkup lengkapnya. Jangan mencoba lagi tanpa filter. Lihat respons span dan ringkasan trace.

Daftar kosong dan record yang tidak ada

Pembacaan daftar bisa tidak punya hasil yang cocok. Pembacaan detail punya kontrak yang berbeda: Log yang tidak ada mengembalikan 404 ini:
Masalah yang tidak ada memakai "error": "issue not found". Ringkasan trace yang tidak ada memakai "error": "trace not found". ID yang tidak dikenal dan ID yang tidak bisa dibaca akun mengembalikan respons yang sama. Daftar dengan satu project_id yang tidak bisa dibaca akun mengembalikan 200 dengan daftar kosong. Periksa ID proyek sebelum Anda melaporkan bahwa tidak ada data.

Pilihan proyek yang ditolak

Daftar log, masalah, aksi, metrik, rilis, dan trace menerima satu proyek dengan project_id atau 2 sampai 50 proyek dengan project_ids. Katalog atribut log menerima pemilih yang sama. Riwayat kemunculan masalah tidak menerimanya. Permintaan yang berisi project_id dan project_ids sekaligus mengembalikan 422:
project_ids dengan UUID yang tidak valid, ID yang berulang, atau kurang dari 2 atau lebih dari 50 ID juga mengembalikan 422 dengan code: validation_failed. Jika akun tidak bisa membaca salah satu proyek di kumpulan project_ids, seluruh permintaan mengembalikan 404. Respons tidak mengembalikan proyek lainnya sebagai hasil sebagian:
Tampilkan error-nya, bukan daftar kosong atau jumlah nol. Baca lagi daftar proyek. Jangan hapus proyek diam-diam, dan jangan mencoba lagi di semua proyek. Kredensial yang didelegasikan, seperti koneksi MCP, mengembalikan 403 dengan code: forbidden untuk proyek di luar koneksinya. Lihat lingkup proyek.

Error kursor

Log, masalah, aksi, metrik, dan kemunculan masalah memakai cursor_time dan cursor_id. Kursor yang ditolak mengembalikan 422 dengan code: validation_failed. Error ini tidak berarti daftarnya kosong. Contoh:
Salin next_cursor lengkap dari halaman sebelumnya. Jangan ganti cursor_time dengan waktu saat ini. Jika kursor hilang, mulai lagi dengan pagination=cursor dan filter aslinya. Kunci kueri yang tidak dikenal atau nilai dengan tipe yang salah mengembalikan 422 dengan "error": "invalid query parameters".

Respons kursor rilis

Kursor rilis punya 5 kolom. Permintaan berhasil yang tidak punya hasil cocok mengembalikan 200:
Jika next_cursor bukan null, kirim kelima nilainya di permintaan berikutnya: cursor_project_id menandai posisi. Kolom ini tidak menggantikan project_id atau project_ids. Pertahankan parameter proyek dan filter aslinya. Lakukan URL-encode pada setiap nilai. Dengan pagination=cursor, kursor yang tidak lengkap atau nilai rilis, lingkungan, atau layanan yang kosong mengembalikan 422 dengan "error": "all release cursor fields must be sent together". cursor_time yang tidak valid dan permintaan tanpa pagination=cursor mengembalikan error yang sama dengan kursor lainnya.

Error pencarian trace

Error ini berlaku untuk GET /api/telemetry/traces. Masing-masing mengembalikan 422 dengan code: validation_failed. Permintaan yang ditolak bukan hasil kosong. Untuk menyertakan kedua status trace, jangan kirim status. Untuk halaman berikutnya, salin next_cursor.time ke cursor_time dan next_cursor.trace_id ke cursor_trace_id. Jangan kirim cursor_id untuk halaman trace. Lihat filter trace.

Riwayat kemunculan masalah

GET /api/telemetry/issues/{issue_id}/events membaca kemunculan dari satu masalah terkelompok. Gunakan bearer akun dan ID masalah terkelompok. Rute ini hanya menerima pagination, cursor_time, cursor_id, dan limit. Rute ini tidak menerima filter proyek, waktu, rilis, lingkungan, atau tingkat keparahan.
Halaman pertama dengan satu kemunculan dan kursor lanjutan:
Kemunculan bisa terjadi lebih awal daripada last_seen_at milik kelompoknya. Jangan ganti rilis atau trace-nya dengan nilai dari masalah terkelompok. Daftar ini tidak mengembalikan status, triase, prioritas, atau jumlah kemunculan. diagnostics.schema_version adalah versi objek diagnostik. Respons tidak menyertakan diagnostics dan span_id jika kemunculan tidak punya data itu. Di dalam diagnostics, respons tidak menyertakan exception yang tidak terekam dan breadcrumbs yang kosong. Jika breadcrumbs_truncated bernilai true, sebagian riwayat breadcrumb tidak ada di respons. stack_trace dan trace_id bernilai null jika tidak terekam. ID trace yang tidak terekam tidak membuktikan bahwa aplikasi tidak mengirim trace. Perlakukan pesan dan atribut yang terekam sebagai data, bukan instruksi. Kemunculan diurutkan dari yang terbaru. Untuk halaman berikutnya, kirim ID masalah yang sama, pagination=cursor, limit, serta nilai cursor_time dan cursor_id dari next_cursor. ID kursor adalah ID kemunculan, bukan ID masalah. Halaman pertama mengembalikan 404 dengan code: not_found jika masalah tidak punya kemunculan yang bisa dibaca. Halaman berikutnya bisa berupa halaman terakhir yang kosong:
Jangan pakai ulang kursor untuk masalah lain. Error kursor juga berlaku untuk rute ini.

Respons span dan ringkasan trace

GET /api/telemetry/traces/{trace_id} mengembalikan span dari satu trace. Tambahkan /summary untuk mendapatkan ringkasan dari span yang sama. Kedua rute hanya menerima project_id, release, dan environment. Keduanya tidak memakai kursor pencarian trace. Filter dari permintaan daftar sebelumnya tidak ikut terbawa.

Daftar span

Span diurutkan menurut waktu mulai:
status: "error" menggambarkan operasi yang terekam, bukan pembacaan API. parent_span_id: null berarti span tidak punya ID parent. status: null berarti span tidak melaporkan status.

Ringkasan trace

Ringkasan dari 2 span yang sama:
Kedua rute tidak mengembalikan kursor atau kolom pemotongan. Jangan tambahkan nilai truncated yang tidak ada di respons.

Tidak ada span yang cocok

Jika tidak ada span yang cocok dengan ID trace dan lingkupnya, daftar span mengembalikan 200 dengan []. Ringkasan mengembalikan 404 dengan "error": "trace not found" dan code: not_found. Periksa ID trace dan lingkupnya. Jangan hapus filter agar hasil muncul. Kedua hasil itu tidak membuktikan bahwa aplikasi tidak mengirim telemetri.

Format respons peristiwa langsung

Feed langsung mengirim peristiwa baru. Feed ini tidak memutar ulang peristiwa yang terlewat oleh klien saat koneksinya terputus. Gunakan rute daftar untuk membaca record yang sudah ada.

Buat tiket

Kirim POST /api/feed/ticket dengan bearer akun. Permintaan ini tidak punya body.
Respons 200 OK berisi tiket di kolom ticket:
Tiket adalah kredensial berumur pendek. Jangan catat tiket di log atau masukkan ke prompt agen. Buka koneksi sebelum expires_in_seconds habis. Masa berlaku ini membatasi kapan koneksi bisa dimulai, bukan berapa lama koneksi tetap terbuka. 401 berarti login akun tidak valid. Masuk lagi sebelum Anda meminta tiket. Metode selain POST mengembalikan 405 dengan code: method_not_allowed.

Buka koneksi

Hubungkan klien WebSocket ke wss://api.logbrew.co/api/feed/live?ticket=<feed-ticket>. Lakukan URL-encode pada tiket. Jangan masukkan bearer akun atau bearer ingest ke URL. 401 berarti tiket atau login akun tidak valid. Buat tiket baru setelah Anda masuk lagi. Tunggu sebelum Anda menyambung ulang setelah error. Jangan menyambung ulang terus-menerus dalam loop tanpa jeda.

Baca pesan

Setiap pesan adalah envelope { "type": "...", "data": ... }. Baca type sebelum Anda mem-parse data. Lewati tipe yang tidak didukung klien.
Peristiwa native_issue memakai respons masalah versi 1: masalah yang diarsipkan tampil sebagai ignored, dan peristiwa ini tidak punya prioritas. Metrik dan rilis bukan tipe peristiwa langsung. Baca keduanya dengan rute daftarnya. Tiket tidak memilih proyek. Periksa project_id setiap peristiwa sebelum Anda menampilkannya di tampilan proyek. logbrew watch --json memakai feed ini. Lihat Referensi CLI.

Tangani koneksi yang tertutup

Koneksi yang terputus karena hal lain bisa tidak punya alasan dari LogBrew. Setelah Anda menyambung ulang, baca lagi rute daftar dan cocokkan record berdasarkan ID.

Contoh respons status masalah

PATCH /api/telemetry/issues/{issue_id} dengan { "status": "resolved" } mengembalikan 200 OK beserta masalah terkelompok yang sudah diperbarui, dalam bentuk yang sama dengan respons masalah. Kunci kueri response_version memilih versinya. Respons ini tidak mengembalikan flag keberhasilan. Body menetapkan 1 atau lebih dari status, priority, dan assignee. status menerima unresolved, resolved, atau archived. ignored adalah nama lama untuk archived. Lihat Perbarui satu masalah. Periksa id, status, dan priority yang dikembalikan sebelum Anda menampilkan keberhasilan. Jangan susun hasil dari nilai yang dikirim. Perubahan status tidak menghapus kemunculan atau mengubah first_seen_at dan last_seen_at. Perubahan ini juga tidak mengubah severity atau aturan tingkat keparahan. Perubahan yang ditolak mengembalikan 422 dengan code: validation_failed:
Kolom yang sudah punya nilai yang diminta tidak berubah. Setelah timeout atau respons yang hilang, kirim lagi permintaan yang sama, atau baca masalahnya dulu. Jangan kirim perubahan lain sebelum Anda membaca status saat ini. Lihat Operasi tulis. POST /api/telemetry/issues/bulk mengembalikan 200 OK dengan 1 hasil untuk setiap ID masalah yang diminta, sesuai urutan permintaan. Setiap masalah yang ditemukan memakai bentuk versi 3. Hasil not_found berisi issue: null:
Contoh ini hanya menampilkan sebagian kolom masalah. outcome bernilai updated, unchanged, atau not_found. Permintaan yang diulang mengembalikan unchanged dan tidak mengubah apa pun. Lihat Perbarui masalah secara massal. Permintaan massal gagal seluruhnya dalam kasus berikut:

Lingkup permintaan analitik

Rute analitik, rute deret metrik, dan rute volume sinyal membaca satu proyek dan satu rentang waktu. Setiap permintaan memerlukan project_id dan since. since menerima durasi ringkas seperti 24h atau 7d, atau stempel waktu RFC3339. until menerima stempel waktu RFC3339 dan default-nya adalah waktu permintaan. Rentang ini mencakup since, tidak mencakup until, dan tidak boleh lebih dari 31 hari. service_name, release, dan environment adalah filter persis yang opsional. Setiap nilai harus berisi 1 sampai 256 karakter setelah LogBrew memangkas spasi. Rute perbandingan segmen menaruh filter ini di dalam setiap segmen, bukan di tingkat atas. Jika akun tidak bisa membaca proyek itu, rute ini mengembalikan 200 OK dengan jumlah nol. Rute ini tidak mengembalikan 404. Hasil kosong tidak memastikan akses ke proyek. Bandingkan project_id dengan proyek yang bisa dibaca akun. Permintaan lewat koneksi MCP yang tidak mencakup proyek itu mengembalikan 403 dan forbidden. Setiap respons diawali dengan schema_version, query, dan purpose. query mengulang lingkup yang berlaku. Kolom ini tidak menyertakan filter yang tidak Anda kirim. purpose adalah teks biasa yang menjelaskan pertanyaan yang dijawab rute itu. Nilai tingkat tidak disertakan jika penyebutnya nol. Tingkat yang tidak disertakan bukan 0 dan bukan null. Baca coverage sebelum Anda memercayai suatu tingkat.

Error lingkup bersama

Error ini memakai HTTP 422 dan validation_failed: Misalnya, permintaan tanpa project_id mengembalikan:
Rute deret metrik dan rute volume sinyal memakai aturan lingkup yang sama, dengan teks error masing-masing. Bagian setiap rute di bawah mencantumkan error tersebut. Kunci kueri yang tidak dikenal mengembalikan 422 dengan respons parameter kueri tidak valid. Kolom JSON yang tidak dikenal, kolom JSON wajib yang tidak ada, atau nilai enum yang tidak didukung mengembalikan invalid_json. Lihat JSON tidak valid. Permintaan dengan metode HTTP yang salah mengembalikan 405 dan method_not_allowed. Teks next-nya menyebutkan metode dan kolom yang didukung. Lihat Metode tidak didukung.

Respons ikhtisar analitik produk

GET /api/telemetry/analytics/overview menampilkan aktivitas di satu proyek: volume aksi, pengguna, sesi, deret waktu, aksi teratas, serta tayangan halaman, tayangan layar, dan interaksi terklasifikasi. Gunakan rute ini untuk menemukan nama peristiwa yang persis bagi rute analitik lainnya. Kirim response_version=3. Versi 1 dan 2 mengembalikan jumlah yang sama, tetapi nilai estimation.method-nya adalah token lama. Versi 1 tidak memeriksa jenis subjek saat menghitung pengguna teridentifikasi. Versi 2 dan 3 hanya menghitung subjek dengan jenis user, serta menambahkan jumlah subjek anonim dan subject_coverage. Permintaan ini membaca 1 jam dalam interval waktu 5 menit dan mengembalikan 2 baris di setiap daftar teratas:

Ikhtisar yang berhasil

Dalam hasil sintetis ini, proyek punya 120 aksi di 2 dari 12 interval waktu. Sebanyak 20 aksi berasal dari subjek anonim. Setiap aksi punya ID sesi. Separuh aksi punya ID trace.

Baca ikhtisar

Kelima jumlah di subject_coverage dijumlahkan menjadi total peristiwa di bagiannya. Hanya identified_user_events yang dihitung sebagai pengguna. anonymous_actions adalah summary.actions dikurangi identified_actions. series hanya berisi interval waktu yang punya aktivitas. expected_buckets adalah jumlah interval waktu yang mungkin ada dalam rentang. Jangan gambar interval waktu yang tidak ada sebagai nol yang terukur, kecuali grafik Anda menyatakan aturan itu. Interval waktu mengikuti batas interval UTC. Rentang yang dimulai di tengah interval waktu menyertakan interval waktu yang belum lengkap itu. classified_activity menghitung tayangan halaman, tayangan layar, dan interaksi. Tayangan layar dan interaksi juga merupakan aksi. Tayangan halaman bukan aksi. Jangan jumlahkan summary.actions dengan classified_activity.summary.events. Salin kind dan event_name dari classified_activity.top_events ke langkah funnel, pemilih retensi, pemilih siklus hidup, jangkar jalur, dan target segmen. Nilai true di top_events_truncated berarti ada nama lain dengan volume lebih rendah. Naikkan top_limit sampai 20 untuk melihat lebih banyak. analysis_level bernilai no_data, event_only, user_level, atau user_and_session. Jika proyek tidak punya aksi dan tidak punya peristiwa terklasifikasi, next_action.code adalah capture_product_activity. Lihat Analitik produk.

Error ikhtisar

Selain error lingkup bersama, ikhtisar mengembalikan 422 dan validation_failed untuk nilai berikut: interval default-nya auto. Nilai ini memilih interval terkecil yang memerlukan paling banyak 300 interval waktu. top_limit default-nya 10.

Respons funnel berurutan

POST /api/telemetry/analytics/funnel mengukur penyelesaian berurutan melalui 2 sampai 8 langkah. Salin setiap kind dan event_name yang persis dari classified_activity.top_events di ikhtisar. Nama aksi yang mirip tidak dihitung cocok. Body permintaan ini menghitung sesi yang membuka /pricing lalu menyelesaikan pendaftaran dalam 1 jam:
analysis_unit bernilai session atau identified_user. Default-nya session. kind langkah bernilai page_view, screen_view, atau interaction. Rute funnel tidak menerima response_version.

Funnel yang berhasil

Respons 200 OK:
Nilai tingkat berupa pecahan dari 0 sampai 1. Baca coverage sebelum Anda memercayai suatu tingkat. selected_unit_coverage_rate adalah porsi peristiwa langkah terpilih yang bisa dipakai LogBrew. Respons tidak mengembalikan identitas mentah. Lihat Analitik produk.

Baca konversi dan cakupan

entry_rate adalah entered_units dibagi candidate_units: 50 dari 60. overall_conversion_rate adalah completed_units dibagi entered_units: 15 dari 50, atau 30%. Nilai ini bukan 15 dibagi semua kandidat. Jumlah ini tidak menjelaskan mengapa unit berhenti. Cakupan menghitung peristiwa, bukan sesi. Di sini, 120 peristiwa cocok dengan satu langkah, dan 20 di antaranya tidak punya ID sesi. Hasilnya mengecualikan 20 peristiwa itu dari jumlah sesi. Jangan anggap peristiwa itu sebagai 20 sesi yang gagal. Langkah pertama tidak punya conversion_from_previous. Langkah terakhir tidak punya drop_off_to_next_units dan drop_off_to_next_rate. Unit mencapai langkah berikutnya hanya jika waktu setiap langkah lebih akhir daripada langkah sebelumnya. Peristiwa dengan stempel waktu yang sama tidak bisa memenuhi 2 langkah yang berurutan. Langkah terakhir harus terjadi dalam conversion_window_seconds sejak langkah pertama. Mode sesi menghitung sesi, bukan orang. Gunakan identified_user hanya untuk peristiwa yang membawa ID subjek buram dengan jenis user. Mode itu bisa menggabungkan peristiwa dari sesi yang berbeda di dalam periode konversi. Gunakan unit dan langkah yang sama saat Anda membandingkan hasil. conversion_window_seconds default-nya 24 jam atau panjang rentang, mana pun yang lebih pendek. Nilai maksimumnya adalah panjang rentang dalam detik penuh, dibulatkan ke atas.

Hasil funnel kosong

Respons kosong yang berhasil tetap mencantumkan langkah yang diminta dengan units nol. Jika tidak ada unit kandidat, summary tidak menyertakan entry_rate dan overall_conversion_rate. Rute ini tidak mengembalikan 404 karena tidak ada peristiwa yang cocok. Baca coverage dan next_action untuk menemukan penyebabnya:

Permintaan funnel yang ditolak

Selain error lingkup bersama, permintaan berikut mengembalikan 422 dan validation_failed. Kurang dari 2 atau lebih dari 8 langkah:
conversion_window_seconds bernilai 0, atau nilai yang melebihi panjang rentang:
event_name yang kosong, lebih dari 256 karakter, atau berisi karakter kontrol mengembalikan product analytics funnel event_name must be non-empty, control-free, and at most 256 characters. Langkah interaction juga harus berupa nama aksi yang valid. Jika tidak, error-nya adalah product analytics interaction event_name must be a bounded stable action name. Perbaiki permintaan sebelum Anda mengirimnya lagi. Jangan hapus langkah atau ubah unit analisis hanya agar hasilnya tidak kosong.

Analisis peristiwa persis dan analisis otomatis

Retensi dan siklus hidup menerima 2 bentuk permintaan. Gunakan response_version untuk memilih bentuk yang menjawab pertanyaan Anda: Pemilih persis berisi kind dan event_name. kind bernilai page_view, screen_view, atau interaction. Salin event_name dari classified_activity.top_events. Jangan menebak nama peristiwa dari label tombol. Kedua bentuk hanya menghitung pengguna: ID subjek buram dengan jenis user. Subjek anonim dan peristiwa tanpa ID subjek yang bisa dipakai tidak dihitung sebagai pengguna. Respons tidak pernah mengembalikan ID subjek. Interval tetap adalah hour, day, week, dan thirty_day. Semuanya berupa durasi tetap. thirty_day berarti 30 hari, bukan 1 bulan kalender. Jika Anda tidak mengirim interval, API memakai hour untuk rentang 48 jam atau kurang, dan day untuk rentang yang lebih panjang.

Permintaan retensi peristiwa persis

Kirim body ini ke POST /api/telemetry/analytics/retention. Permintaan ini menanyakan apakah pengguna menyelesaikan checkout lagi setelah checkout pertama mereka dalam rentang:
Peristiwa awal pertama yang cocok dalam rentang menjadi titik awal setiap pengguna. Peristiwa kembali harus terjadi setelah titik awal itu dan sebelum until. Kedua pemilih boleh berupa peristiwa yang sama.

Retensi peristiwa persis yang berhasil

Dalam contoh sintetis ini, 2 pengguna menyelesaikan checkout. Pengguna pertama menyelesaikan checkout pada pukul 12.00 tanggal 1 Juni dan sekali lagi pada pukul 13.00. Pengguna kedua menyelesaikan checkout pada pukul 12.00 tanggal 2 Juni. Pada pukul 13.00 tanggal 2 Juni, pengguna kedua membuka satu halaman, tetapi tidak menyelesaikan checkout lagi.

Baca retensi

Cakupan menghitung keempat peristiwa terklasifikasi, tetapi hanya 3 yang cocok dengan setiap pemilih checkout. Tayangan halaman tidak dihitung sebagai peristiwa kembali. Salah satu dari 2 pengguna mengulang checkout, jadi return_rate_after_start bernilai 0.5. Hanya pengguna pertama yang punya 1 hari pengamatan penuh setelah titik awal. Pengguna itu kembali dalam hari yang sama, jadi tingkat di kurva bernilai 1.0. Pengguna kedua hanya punya 12 jam pengamatan. Pengguna itu belum memenuhi syarat untuk periode 0, jadi sel kohort kedua tidak menyertakan retention_rate. Jangan hitung pengguna itu sebagai hilang. weighted_retention_rate membagi semua pengguna yang bertahan dengan semua pengguna yang memenuhi syarat. fully_observed_cohort_average_rate adalah rata-rata biasa dari tingkat kohort yang semua penggunanya memenuhi syarat. Kohort adalah interval waktu tetap yang dimulai pada since. cohorts hanya berisi kohort yang punya pengguna. Dengan mode: "return_on_or_after", kurva tidak menyertakan window_end_seconds.

Retensi otomatis

Kirim response_version: 2 tanpa start_event atau return_event. Setiap tayangan halaman, tayangan layar, dan interaksi yang didukung dihitung sebagai peristiwa awal sekaligus peristiwa kembali. Versi ini memilih sekumpulan peristiwa. Versi ini tidak memilih format perekaman SDK.
Respons punya bentuk summary, curve, cohorts, dan next_action yang sama dengan respons peristiwa persis. Kutipan ini menampilkan kolom yang berubah. Dalam contoh ini, 2 pengguna yang sama punya 3 peristiwa dan tidak ada tayangan halaman:
Dalam mode otomatis, start_events dan return_events sama-sama bernilai classified_events. Jumlah ini menghitung peristiwa, bukan pengguna.

Retensi tanpa pengguna yang memenuhi syarat

Hasil yang berhasil bisa tidak punya pengguna kohort. Kutipan ini menampilkan 1 periode yang diminta tanpa kohort:
Baca coverage dan next_action. Keduanya membedakan lingkup tanpa peristiwa terklasifikasi (capture_product_activity) dari peristiwa tanpa pengguna (identify_product_users atau identify_returning_users). Tingkat yang tidak ada bukan nol yang terukur.

Error retensi

Selain error lingkup bersama, permintaan berikut mengembalikan 422 dan validation_failed: Batas sel memakai rentang dan periode, bukan jumlah pengguna. Rentang 30 hari dengan interval: "hour" punya 720 interval waktu kohort. Dengan interval_count: 1, itu berarti 720 sel, lebih dari 500:
Untuk memakai retensi otomatis, hapus kedua pemilih. Jangan ubah SDK untuk memperbaiki permintaan baca ini.

Permintaan siklus hidup peristiwa persis

Kirim body ini ke POST /api/telemetry/analytics/lifecycle. Permintaan ini mengelompokkan pengguna berdasarkan satu peristiwa, bukan berdasarkan semua aktivitas di proyek:
history_period_count menentukan jumlah periode lengkap sebelum since yang dibaca LogBrew sebagai riwayat. Nilainya 2 sampai 31. Default-nya 2. Pengguna bisa tidak aktif untuk peristiwa ini meskipun ia melakukan aktivitas lain.

Siklus hidup peristiwa persis yang berhasil

Contoh sintetis ini memakai 2 hari riwayat dan 2 hari analisis. Huruf di sini hanya menandai pengguna contoh. Respons tidak mengembalikan ID pengguna. Pada 2 Juni, C juga membuka satu halaman. Peristiwa itu tidak cocok dengan pemilih checkout.

Baca siklus hidup

Pada 1 Juni, A masuk kelompok “Kembali”, B “Aktif kembali”, C “Baru dalam riwayat teramati”, dan D “Tidak aktif”. Pada 2 Juni, A dan B masuk kelompok “Kembali”, sedangkan C “Tidak aktif” untuk checkout meskipun membuka satu halaman. Perubahan bersih pada 2 Juni adalah 2 - 3 = -1. Di setiap interval waktu, jumlah pengguna “Baru dalam riwayat teramati”, “Kembali”, dan “Aktif kembali” sama dengan active_subjects. returning_subjects ditambah dormant_subjects sama dengan previous_active_subjects. net_active_change adalah active_subjects dikurangi previous_active_subjects. Jangan jumlahkan angka aktif harian untuk mendapatkan pengguna unik. Di sini, angka harian berjumlah 5, tetapi analysis_active_subjects bernilai 3. Ada 4 pengguna unik di seluruh riwayat dan analisis. fully_observed bernilai false untuk interval waktu terakhir yang berakhir setelah until. Jumlah di dalamnya bisa berubah saat seluruh periode sudah bisa diamati. next_action menyarankan investigasi. Nilai ini tidak menunjukkan penyebab.

Siklus hidup otomatis

Kirim response_version: 2 tanpa pemilih event. Setiap tayangan halaman, tayangan layar, dan interaksi yang didukung dihitung sebagai aktivitas:
Respons punya bentuk summary, buckets, dan next_action yang sama dengan respons peristiwa persis. Kutipan ini menampilkan kolom yang berubah:
Dalam mode otomatis, coverage.selected_events sama dengan coverage.analysis_classified_events. Entri limitations kelima adalah Returning, resurrected, and dormant compare any supported classified product activity; no event is ranked, selected, or inferred.

Siklus hidup tanpa pengguna

Jika rentang analisis dan riwayat sama-sama tidak berisi pengguna yang bisa dipakai, buckets kosong dan summary tidak menyertakan latest_fully_observed_period:
Pengguna yang hanya muncul di riwayat tetap bisa menghasilkan interval waktu dengan pengguna yang tidak aktif jika rentang analisis tidak punya aktivitas.

Error siklus hidup

Selain error lingkup bersama, permintaan berikut mengembalikan 422 dan validation_failed: Misalnya, 10 periode riwayat week memerlukan 70 hari:

Baca lingkup analisis yang dipilih

Respons peristiwa persis punya schema_version: 1. query-nya mengulang pemilih dan tidak menyertakan activity_scope. Respons otomatis punya schema_version: 2 dan query.activity_scope: "all_classified_activity". Respons ini tidak menyertakan pemilih. Pemilih yang berbeda bisa mengubah hasil tanpa perubahan apa pun pada aktivitas yang terekam.

Respons deret metrik

GET /api/telemetry/metrics/series membaca satu nama metrik yang persis di satu proyek. Salin nama itu dari GET /api/telemetry/metrics. Permintaan ini mengelompokkan counter delta berdasarkan layanan:

Deret metrik yang berhasil

Respons sintetis ini berisi 1 deret counter delta. Tiga sampel dengan nilai 2, 3, dan 5 terjadi di interval waktu pertama. Dua sampel dengan nilai 1 dan 4 terjadi di interval waktu terakhir. Tidak ada sampel di interval waktu tengah, jadi respons tidak punya titik data untuknya.

Baca deret metrik

Titik data pertama mencatat 10 job yang selesai, bukan 10 sampel. rate_per_second membagi perubahan itu dengan interval waktu 300 detik. last adalah perubahan terakhir yang tercatat, bukan jumlahnya. Lihat arti agregasi metrik. Jenis dan temporalitas sebuah deret menentukan aggregation.code-nya dan statistik di setiap titik data. Titik data tidak menyertakan statistik yang tidak berlaku. Statistik yang tidak ada bukan nol. limited adalah respons yang berhasil, bukan error. Status ini menambahkan aggregation.limitation, yang menjelaskan mengapa LogBrew hanya menampilkan nilai mentah. ready tidak membuktikan perekaman yang lengkap. Baca coverage sebelum Anda menggambar grafik:
  • samples menghitung sampel dari semua deret yang cocok, termasuk deret yang tidak dikembalikan respons.
  • series menghitung deret yang cocok. returned_series dan points menghitung data yang dikembalikan.
  • truncated bernilai true jika series_limit membuang deret bervolume lebih rendah.
  • expected_buckets_per_series adalah jumlah interval waktu yang mungkin ada dalam rentang.
Jangan tambahkan titik data untuk interval waktu tanpa sampel. Jangan sisipkan nol atau salin nilai sebelumnya. Setiap titik data mengembalikan paling banyak 3 trace_exemplars. Exemplar trace menautkan satu sampel ke satu trace. Exemplar itu tidak menjelaskan setiap sampel di interval waktu tersebut. Jika tidak ada titik data yang punya exemplar trace, next_action.target adalah metric_samples.

Lingkup dan error deret metrik

project_id, name, dan since wajib dikirim. name paling banyak berisi 200 karakter. interval bernilai auto, 1m, 5m, 15m, 1h, 6h, atau 1d. Default-nya auto, yang memilih interval terkecil dengan paling banyak 300 interval waktu. Interval eksplisit tidak boleh memerlukan lebih dari 500 interval waktu. group_by bernilai none, service_name, release, atau environment. Default-nya none. Tanpa pengelompokan, jenis, unit, dan temporalitas yang berbeda tetap berada di deret terpisah. series_limit menerima 1 sampai 20. Default-nya 10. Hasil kosong mengembalikan 200 dengan series: [] dan samples nol. Objek coverage tidak menyertakan first_seen_at dan last_seen_at. Ini tidak membuktikan bahwa aplikasi tidak pernah mengirim metrik itu. Periksa proyek, nama metrik, dan rentang waktunya. Permintaan tanpa name mengembalikan 422:
Interval waktu 1 menit selama 7 hari mengembalikan 422:
Error 422 lainnya adalah metric series group_by is not supported, metric series interval is not supported, dan metric series_limit must be between 1 and 20.

Respons analisis jalur

POST /api/telemetry/analytics/paths menemukan peristiwa bernama sebelum atau sesudah satu peristiwa terpilih dalam sesi yang sama. Peristiwa terpilih itu adalah jangkar. Salin kind dan event_name-nya dari classified_activity.top_events. Rute ini mengembalikan schema_version: 1. Rute ini tidak menerima response_version atau analysis_unit.
direction dan anchor wajib dikirim.

Jalur yang berhasil

Dalam hasil sintetis ini, 4 sesi berisi jangkar. Kedua jalur yang dikembalikan mewakili 3 dari sesi itu. Satu jalur dengan peringkat lebih rendah tidak dikembalikan.

Baca jalur

share_of_anchored_sessions membagi sesi sebuah jalur dengan keempat sesi yang berisi jangkar. Porsinya 50% dan 25%, bukan 67% dan 33%. unrepresented_sessions menghitung sesi berjangkar yang tidak diwakili jalur mana pun yang dikembalikan. paths_truncated: true berarti hasilnya belum lengkap. Cakupan menghitung peristiwa, bukan sesi. Di sini, 5 peristiwa cocok dengan jangkar, tetapi 1 di antaranya tidak punya ID sesi. Peristiwa itu tidak bisa masuk ke jalur. Setiap jalur mengembalikan paling banyak 3 exemplar trace. Gunakan ID trace dari respons Anda sendiri. Tautan trace tidak menunjukkan apa yang menyebabkan aksi pengguna atau kegagalan. Node diurutkan menurut waktu di kedua arah. Jalur bukan pemutaran ulang sesi secara lengkap. LogBrew membaca paling banyak 1.024 peristiwa bernama per sesi sebelum memilih jangkar: peristiwa paling awal untuk following dan peristiwa paling akhir untuk preceding. Jangkar di luar batas itu bisa tidak disertakan.

Filter jangkar berdasarkan properti

Kirim paling banyak 4 property_filters, masing-masing dengan satu key dan value yang persis. Salin kuncinya dari katalog properti. Filter hanya berlaku untuk jangkar, bukan untuk peristiwa di sekitarnya. Nilai peka huruf besar-kecil. Jika ada filter, query mengulangnya, dan coverage.anchor_property_filters melaporkan: Kunci yang tidak ada dan nilai yang berbeda memerlukan perbaikan yang berbeda. Jangan jumlahkan keduanya. Objek ini tidak disertakan jika permintaan tidak punya filter properti.

Jalur kosong dan permintaan yang ditolak

Array paths yang kosong bisa berupa respons 200 yang berhasil. Baca summary, coverage, dan next_action. Kode berikut membedakan penyebabnya: capture_product_activity, choose_captured_path_anchor, capture_anchor_properties, improve_anchor_property_coverage, verify_anchor_property_values, sessionize_product_activity, dan narrow_or_move_path_anchor. Selain error lingkup bersama, permintaan berikut mengembalikan 422 dan validation_failed: Misalnya, depth: 0 mengembalikan:

Katalog properti analitik

GET /api/telemetry/analytics/properties menampilkan daftar kunci properti pada peristiwa produk terklasifikasi di satu proyek. Gunakan kunci itu di perbandingan segmen dan filter jangkar jalur. Katalog mengembalikan kunci dan jumlah. Katalog tidak pernah mengembalikan nilai properti atau identitas.

Baca kunci properti yang tersedia

Kirim project_id dan since. Anda juga bisa mengirim until, service_name, release, environment, limit, dan response_version. limit menerima 1 sampai 50 kunci. Default-nya 20. Kirim response_version=2 untuk mendapatkan nilai estimation.method publik.

Katalog properti yang berhasil

Dalam hasil sintetis ini, ada 100 peristiwa terklasifikasi. Lima di antaranya terekam sebelum indeks properti saat ini dibuat.

Tafsirkan katalog

source bernilai standard_context untuk kunci konteks standar, seperti resource.runtime.name, atau custom_tag untuk kunci yang diawali tag.. value_type selalu string. properties diurutkan menurut events, dari yang terbanyak. tag.plan ada di 60 dari 100 peristiwa terklasifikasi. Kunci ini punya sekitar 3 nilai yang berbeda. Deskriptornya tidak menampilkan nilai itu. Gunakan nilai yang Anda ketahui dari aplikasi Anda. Jangan menebak nilai dari sebuah jumlah. Satu peristiwa bisa punya beberapa kunci, jadi jangan jumlahkan angka events per kunci. Array properties yang kosong tidak membuktikan bahwa proyek tidak punya peristiwa produk. Baca summary, coverage, dan next_action.

Error katalog properti

Selain error lingkup bersama, limit=0 atau limit=51 mengembalikan 422:
response_version selain 1 atau 2 mengembalikan product analytics response_version must be 1 or 2. LogBrew memeriksa response_version sebelum nilai lainnya. Permintaan POST mengembalikan 405:

Perbandingan segmen analitik

POST /api/telemetry/analytics/segments/compare membandingkan seberapa sering sesi atau pengguna mencapai satu peristiwa persis di 2 sampai 4 segmen dalam satu proyek. Segmen memilih peristiwa berdasarkan layanan, rilis, lingkungan, dan nilai properti. Segmen pertama menjadi acuan.

Tentukan perbandingan

Kirim body JSON ini dengan autentikasi akun dan Content-Type: application/json. Di sini, basic dan premium adalah nilai paket dari aplikasi contoh, bukan paket LogBrew:
target dan segments wajib dikirim. analysis_unit bernilai session atau identified_user. Default-nya session, yang menghitung sesi, bukan orang. interval menerima nilai yang sama dengan ikhtisar. Default-nya auto. Setiap segmen memerlukan key yang unik, label, dan kumpulan filter yang berbeda:
  • key: 1 sampai 32 byte. Awali dengan huruf ASCII kecil atau angka. Gunakan hanya huruf ASCII kecil, angka, _, dan -.
  • label: 1 sampai 80 karakter, tanpa karakter kontrol.
  • service_name, release, environment: opsional. Setiap nilai berisi 1 sampai 256 karakter, tanpa karakter kontrol.
  • property_filters: 0 sampai 4 filter. Setiap kunci hanya boleh muncul sekali dalam satu segmen. Peristiwa harus cocok dengan semua filter segmen. Nilai peka huruf besar-kecil, berisi 1 sampai 256 karakter, dan LogBrew memangkas spasi di awal dan akhir.
Segmen tanpa filter memilih semua aktivitas terklasifikasi di proyek dan rentang waktu itu. Segmen bisa saling tumpang-tindih. Label atau kunci yang berbeda tidak membuat 2 kumpulan filter yang identik menjadi valid.

Perbandingan segmen yang berhasil

Dalam hasil sintetis ini, segmen acuan mencapai checkout di 10 dari 50 sesi. Segmen premium mencapainya di 18 dari 60 sesi.

Baca tingkat dan selisih

eligible_units memperkirakan jumlah sesi atau pengguna yang punya aktivitas terklasifikasi di segmen itu. reached_units memperkirakan berapa banyak di antaranya yang mencapai target. reach_rate adalah reached_units dibagi eligible_units. Peristiwa tanpa ID unit yang dipilih tidak dihitung dalam unit ini. Tingkat segmen acuan adalah 20%. Tingkat segmen premium adalah 30%. Selisihnya 10 poin persentase. Kenaikan relatifnya 50%, bukan 10%. Ketidaktepatan desimal yang kecil berasal dari aritmetika floating-point. Bulatkan tingkat untuk tampilan, tetapi hitung dengan nilai yang dikembalikan. Segmen acuan tidak punya comparison_to_baseline. Kenaikan relatif tidak disertakan jika tingkat pencapaian segmen acuan bernilai nol. Di query, filter segmen yang tidak Anda kirim bernilai null. Daftar property_filters yang kosong tidak disertakan. coverage.property_filters punya kolom yang sama dengan cakupan filter jangkar jalur. Di sini, matching_events sama dengan classified_events. Pisahkan kunci yang tidak ada dari nilai yang berbeda. Segmen bisa saling tumpang-tindih, dan satu sesi bisa muncul di beberapa interval waktu. Jangan jumlahkan angka unit lintas segmen atau lintas interval waktu. Perbandingan ini bersifat deskriptif. confidence.causal_inference bernilai not_established dan confidence.statistical_significance bernilai not_tested. Tingkat 30% dibandingkan 20% tidak menunjukkan bahwa sebuah paket menyebabkan lebih banyak checkout.

Error perbandingan segmen

Selain error lingkup bersama, permintaan berikut mengembalikan 422 dan validation_failed: Error interval sama dengan error ikhtisar. Misalnya, 2 segmen dengan kunci berbeda dan filter identik mengembalikan:
Label yang berbeda atau urutan filter properti yang berbeda tidak mengubah peristiwa yang dipilih. Kegagalan validasi bukan bukti bahwa tidak ada peristiwa yang cocok. Permintaan GET mengembalikan 405:

Respons volume sinyal

GET /api/telemetry/summary/volume menghitung sinyal yang tersimpan untuk satu proyek dan rentang waktu. Rute ini memerlukan project_id dan since. Rute ini tidak menerima project_ids. until tidak boleh berada di masa depan. Jika Anda tidak mengirimnya, akhir rentang adalah waktu permintaan. since ringkas seperti 24h dihitung mundur dari until. interval bernilai auto, 1m, 5m, 15m, 1h, 6h, atau 1d. Default auto memilih interval terkecil dengan paling banyak 120 interval waktu. Permintaan tidak boleh memerlukan lebih dari 500 interval waktu. Satu-satunya response_version adalah 1.

Jumlah sinyal

Respons sintetis ini mencakup 2 interval waktu 1 menit. Permintaan berjalan pada pukul 12.02 UTC tanpa until. Akun ini punya kebijakan retensi data 30 hari. Baca kebijakan dan batas waktu yang dikembalikan. Jangan anggap nilai ini berlaku untuk akun Anda.

Baca setiap jumlah dalam satuannya sendiri

total adalah jumlah angka interval waktu dalam deret itu. peak adalah angka interval waktu terbesarnya. non_empty_buckets menghitung interval waktu yang angkanya di atas nol. Kelima deret selalu muncul dengan urutan ini. Jangan gabungkan jumlah sinyal yang berbeda menjadi satu skor dampak. Interval waktu dimulai pada query.since. Interval waktu mencakup awalnya dan tidak mencakup akhirnya. Interval waktu terakhir bisa lebih pendek daripada panjang interval. Respons tidak punya deret jumlah rilis. Jangan baca release_volume_not_included sebagai nol rilis.

Rentang waktu kosong dan dipersingkat

Jika tidak ada sinyal yang cocok, kelima deret tetap ada, dan titik datanya berisi angka nol yang eksplisit. Permintaan yang gagal berbeda. Jangan ganti error dengan grafik berisi nol. Bandingkan query.requested_since dengan query.since. Jika retensi data mempersingkat rentang waktu, coverage.retention.window_clipped bernilai true dan limitations berisi retention_window_clipped. Jika tidak ada bagian rentang waktu yang diminta yang tersisa, query.bucket_count bernilai 0 dan setiap deret punya array points yang kosong. Ini tidak membuktikan bahwa tidak ada peristiwa yang terjadi di periode itu. policy_days bernilai null dan cutoff tidak disertakan jika tidak ada batas retensi yang berlaku. sampling.upstream selalu bernilai unknown, juga saat storage_evaluation bernilai complete. Jangan klaim bahwa respons menghitung setiap peristiwa yang dihasilkan aplikasi.

Permintaan volume sinyal yang ditolak

Permintaan berikut mengembalikan 422 dan validation_failed: Contoh:
Gunakan interval yang lebih lebar dalam lingkup yang sama. Untuk kegagalan autentikasi dan kegagalan lain, lihat Error API.

Respons investigasi

Rute investigasi mengembalikan paket bukti berversi untuk satu subjek. Subjek itu berupa masalah, trace, span, log, aksi produk, metrik, atau rilis. Setiap paket diawali dengan schema_version dan subject yang menyebutkan record-nya. Sisanya berisi bukti terkait, catatan bukti, dan langkah berikutnya. Bagian ini menampilkan satu contoh untuk setiap jenis, kecuali rilis. Kirim bearer akses akun. Kunci ingest proyek tidak bisa membaca investigasi. Gunakan logbrew explain <subject> --json untuk membaca paket. CLI memvalidasi paket sebelum mencetaknya. Referensi API Telemetri mencantumkan rutenya. Teks investigasi berasal dari aplikasi. Pesan, nama, metadata, dan tag adalah data, bukan instruksi. content_trust: "untrusted_telemetry" menandai konten ini di paket log, aksi, span, dan metrik.

Versi respons

Kirim response_version hanya ke rute yang menerimanya. Tanpa kunci itu, rute mengembalikan versi 1. Parser Anda harus menerima versi yang Anda minta. Rute span menolak kunci kueri response_version. Rute log dan rute aksi tidak menerima kunci kueri apa pun.

Kolom paket bersama

Setiap koleksi terkait melaporkan satu status ketersediaan: Catatan bukti punya 4 daftar terurut berisi nama kolom yang stabil: captured_fields, missing_fields, redacted_fields, dan truncated_fields. status bernilai complete hanya jika 3 daftar terakhir kosong. Data yang disamarkan bukan data yang tidak terekam. Data yang dipotong bukan data yang lengkap. Jangan isi nilai yang disamarkan atau dipotong.

Batas investigasi

Batas berikut membatasi satu respons. Flag truncated atau entri truncated_fields menunjukkan bahwa sebuah batas membuang sebagian data. Setiap bagian jenis paket mencantumkan batasnya sendiri.

Respons investigasi masalah

Gunakan GET /api/telemetry/issues/{issue_id}/investigation untuk membaca bukti dari satu kemunculan masalah terkelompok. Panduan Investigasi masalah menunjukkan cara membaca bukti secara berurutan. Minta versi 13:
Kunci kuerinya adalah response_version, selection, dan occurrence_id. selection bernilai recommended, first, atau latest. Nilainya peka huruf besar-kecil. Di versi 2 sampai 13, pemilih yang tidak dikirim memakai recommended. Versi 1 mengembalikan kemunculan tersimpan terbaru dan tidak menerima pemilih. Filter daftar masalah tidak berlaku untuk pembacaan ini.
Respons 200 OK sintetis ini punya satu kemunculan TypeError yang ditangani, dengan trace yang tertaut. Respons ini tidak punya bukti permintaan, breadcrumb, log terkait, atau deployment, jadi evidence.status bernilai partial.
Kunci dari versi yang lebih baru tidak ada di versi yang lebih lama. Jangan baca kunci yang tidak ada sebagai null. subject.status dan status di lifecycle melaporkan masalah yang diarsipkan sebagai ignored. Respons daftar dan detail masalah memakai archived di versi respons 2 dan yang lebih baru. Batas masalah: rekomendasi membaca paling banyak 50 kemunculan yang tersimpan. Tren punya paling banyak 30 interval waktu. Setiap distribusi mengembalikan paling banyak 10 nilai. Stack punya paling banyak 32 frame.

Error permintaan investigasi masalah

Gunakan selection atau occurrence_id, salah satunya saja. Jangan kirim keduanya, meskipun keduanya memilih kemunculan yang sama:
Kemunculan yang tidak ada tidak berarti masalahnya juga tidak ada. 404 tidak menunjukkan apakah akun lain bisa membaca masalah itu.

Respons investigasi trace

Gunakan GET /api/telemetry/traces/{trace_id}/investigation untuk membaca satu trace beserta jalur kegagalannya, jalur paling lambatnya, dan sinyal terkait. Kunci kuerinya adalah response_version, project_id, release, dan environment. Semuanya opsional. Minta versi 3:
Versi 2 menambahkan cause dan fix ke setiap masalah terkait. Versi 3 menambahkan span_id ke masalah, aksi, dan metrik terkait jika span_id terekam.
Respons sintetis ini punya root span server dan span klien yang gagal. Span yang gagal itu juga merupakan child span paling lambat. Kedua span tidak punya konteks terstruktur, jadi spans.context tidak terekam.
trace.parentage tidak terekam jika span menyebut parent yang tidak disimpan LogBrew. Pratinjau span berisi paling banyak 64 span. Setiap jalur analisis berisi paling banyak 64 span. Pembacaan terkait memakai paling banyak 8 lingkup deployment. Langkah berikutnya dengan target trace_span menyebutkan span_id dari paket ini. Untuk membaca span itu, kirim rute span dengan project_id, environment, dan release milik span tersebut.

Respons investigasi span

Gunakan GET /api/telemetry/traces/{trace_id}/spans/{span_id}/investigation untuk membaca satu operasi dalam trace. Kirim project_id, environment, dan release. Ketiganya wajib dikirim. Salin nilainya dari span yang dipilih. Jangan kirim id baris span sebagai span_id.
Respons sintetis ini menggambarkan span klien yang gagal dari contoh trace. Satu log error punya ID span yang sama. Span ini berjalan lebih lama daripada perkiraan persentil ke-95 dari span sejenis yang tersimpan.
Acuan membaca 24 jam sebelum span dimulai. since inklusif dan until eksklusif. error_rate_basis_points: 500 berarti 5%. subject_percentile_basis_points: 9500 berarti 95% span sejenis yang tersimpan tidak berjalan lebih lama daripada span ini. Persentil bersifat perkiraan. Sertakan baseline.limitations bersama nilainya. Acuan not_found tidak punya span sejenis yang tersimpan. Acuan unavailable adalah pembacaan yang gagal, bukan jumlah nol. parent_chain_status: "complete" berarti rantai yang tersimpan mencapai root. Ini tidak membuktikan bahwa LogBrew menyimpan setiap span dari permintaan itu. Topologi mengembalikan paling banyak 64 ancestor, 50 child langsung, dan 50 edge lintas layanan.

Respons investigasi log

Gunakan GET /api/logs/{log_id}/investigation untuk membaca satu log dan bukti terkaitnya. Rute ini tidak punya kunci kueri. Salin ID log dari daftar log.
Pembacaan ini bisa mengembalikan bukti di luar filter daftar log. Pembacaan terkait memakai proyek, lingkungan, dan rilis log itu, serta 5 menit sebelum dan sesudah log. Log di sekitarnya juga memakai layanan yang sama dan tidak memerlukan ID trace. Pembacaan trace persis memerlukan ID trace log dan bisa mencakup layanan lain. Ringkasan trace memakai ID trace dan lingkup yang sama, tanpa rentang waktu.
Respons sintetis ini punya log peringatan tanpa konteks trace dan satu log di sekitarnya. Respons tidak membangun tautan trace dari stempel waktu.
ID trace bisa ada meskipun status trace bernilai not_found atau unavailable. Ringkasan trace yang tersedia tidak menjamin adanya exact_span.

Respons investigasi aksi

Gunakan GET /api/telemetry/actions/{action_id}/investigation untuk membaca satu aksi produk, status yang dilaporkannya, dan bukti terkait. Rute ini tidak punya kunci kueri. Pembacaan terkait memakai rentang waktu dan lingkup yang sama dengan investigasi log.
correlations, timeline, dan next_actions memakai bentuk investigasi log. Aksi terkait tidak menyertakan aksi subjek.
Respons sintetis ini menggambarkan aksi checkout yang gagal dari pengguna yang sudah masuk. Aksi ini tidak punya ID trace.
Respons tidak pernah mengembalikan ID subjek atau ID sesi. Catatan bukti selalu mencantumkan subject.distinct_id sebagai disamarkan, dan juga subject.session_id jika sesi terekam. Karena itu, setiap paket aksi bernilai partial dan menyertakan improve_capture. Jangan hapus kontrol privasi hanya untuk memenuhinya.

Respons investigasi metrik

Gunakan GET /api/telemetry/metrics/investigation untuk membaca satu nama metrik di satu proyek dan rentang waktu. Respons berisi deret saat ini, perbandingan dengan rentang waktu sebelumnya yang sama panjang, sampel terbaru, exemplar trace, dan deployment yang sudah selesai. Versi 2 menambahkan deskripsi metrik dari sampel tersimpan terbaru. Versi 1 selalu melaporkan description_status: "not_captured".
project_id, name, dan since wajib dikirim. since inklusif dan until eksklusif. until default-nya adalah waktu saat ini. Perbandingan juga membaca rentang waktu sebelumnya yang sama panjang.
Histogram sintetis ini punya 5 sampel di 2 interval waktu 5 menit. Interval waktu terbaru punya p95 sebesar 48 ms. Interval waktu terbaru di rentang waktu sebelumnya punya p95 sebesar 24 ms.
relative_change_percent adalah (current - previous) / abs(previous) * 100. Nilainya null jika nilai sebelumnya nol atau tidak ada. expected_buckets_per_series menghitung interval waktu yang mungkin ada, bukan interval waktu yang punya data. Jangan gambar interval waktu kosong sebagai nol. Deployment yang terjadi di dekat suatu perubahan tidak membuktikan bahwa deployment itu menyebabkan perubahan tersebut. Proyek yang tidak bisa dibaca akun mengembalikan 200 OK dengan analysis.status: "no_samples", bukan 404. Hasil kosong tidak menggambarkan tipe sinyal lain. Batas metrik: rentang paling lama 31 hari. Setiap deret punya paling banyak 500 interval waktu. series_limit bernilai 1 sampai 20, dengan default 10. Respons mengembalikan paling banyak 20 exemplar dan 20 deployment. interval bernilai auto, 1m, 5m, 15m, 1h, 6h, atau 1d. group_by bernilai none, service_name, release, atau environment. Nilai lain mengembalikan 422.

Error investigasi

404 berarti tidak ada proyek yang bisa dibaca yang punya record itu. Setiap rute juga mengembalikan 401 tanpa autentikasi yang valid dan 405 untuk metode selain GET. Lihat Error API untuk respons tidak ditemukan, path, autentikasi, dan metode. Pembacaan bukti opsional bisa gagal di dalam respons 200 OK. Dalam kasus itu, koleksinya melaporkan unavailable. Jangan tampilkan sebagai not_found atau sebagai nol record.

Nilai tingkat keparahan

Nilai tingkat keparahan yang tampil ke pengguna adalah info, warning, error, dan critical. SDK dan runtime bisa mengirim alias umum seperti trace, debug, warn, atau fatal. Respons REST dan respons langsung selalu mengembalikan nilai kanonis. Misalnya, LogBrew menerima warn sebagai input dan mengembalikan warning. Ingest menolak nilai tingkat keparahan yang tidak dikenal.

Respons aturan tingkat keparahan

Aturan tingkat keparahan mengubah cara LogBrew menampilkan log atau masalah. Aturan ini tidak mengubah tingkat keparahan yang direkam aplikasi. Log dan masalah mengembalikan objek triage: Gunakan triage.effective_severity untuk tampilan. Pertahankan severity sebagai nilai yang terekam. Secara default, daftar log tidak menyertakan log yang diabaikan. Kirim status=ignored atau status=all di GET /api/logs untuk menyertakannya. Akun harus punya izin untuk mengelola masalah di proyek itu. Akses baca tidak cukup. Tanpa izin itu, perubahan aturan mengembalikan 403 dengan code: forbidden.

Ubah aturan log

PUT /api/logs/{log_id}/triage-rule menetapkan aturan untuk log itu dan untuk log berikutnya dengan signature yang sama. Body memerlukan severity dan ignored sekaligus:
Respons 200 OK berisi log lengkap. severity-nya tetap warning. triage-nya menampilkan aturan itu:
Kutipan ini hanya menampilkan kolom yang berubah. severity di permintaan bernilai source, info, warning, error, atau critical. source memulihkan tingkat keparahan yang terekam. Nilai ini tidak membuat log yang diabaikan aktif kembali. Untuk menampilkan log itu lagi, kirim "ignored": false.

Ubah aturan masalah

PUT /api/telemetry/issues/{issue_id}/triage-rule menetapkan tingkat keparahan yang ditampilkan untuk masalah terkelompok dan kemunculan berikutnya. Body hanya menerima severity:
Respons 200 OK berisi masalah lengkap dalam versi 1. severity dan status yang terekam tidak berubah:
Kutipan ini hanya menampilkan sebagian kolom. Aturan tidak menyelesaikan, mengarsipkan, atau membuka kembali masalah. Gunakan perubahan status untuk itu. Prioritas turunan mengikuti tingkat keparahan efektif yang baru. Baca masalah itu dengan response_version=2 atau 3 untuk melihatnya. Tingkat keparahan yang tidak didukung mengembalikan 422:
Kolom body yang tidak dikenal, seperti status pada aturan masalah, mengembalikan 422 dengan code: invalid_json. Log atau masalah yang tidak ada atau tidak bisa dibaca mengembalikan 404 dengan code: not_found. Jika respons hilang, baca lagi log atau masalahnya sebelum Anda mengirim aturan itu lagi.

Format respons error

Error aplikasi mengembalikan envelope JSON. Contoh ini menampilkan permintaan yang ditolak; teks error dan next bergantung pada jenis error-nya:
Gunakan code untuk percabangan program dan next_action untuk otomatisasi. Tampilkan error dan next sebagai teks biasa untuk dibaca orang. Jangan mem-parse kata-katanya. Beberapa error menambahkan kolom, seperti limit, reset_at, atau retry_after_seconds. Respons tanpa body JSON tidak punya code LogBrew. Lihat Error API untuk semua kode.

Baca data dengan CLI

CLI membaca rute yang sama dan mengembalikan JSON yang sama dengan --json. Mulai secara luas, lalu persempit:
Tambahkan --pagination cursor untuk mendapatkan envelope kursor. CLI meminta versi respons masalah 4. Lihat Baca halaman berikutnya dan Pantauan langsung.