Wawancara Desain Sistem: Bagaimana Anda Mendesain Platform Distributed Tracing?

Prompt dan Cakupan

Rancang platform distributed tracing multi-tenant yang digunakan oleh tim backend dan reliabilitas untuk melacak satu permintaan atau alur kerja asinkron di seluruh layanan. Asumsi wawancara adalah 500.000 root workflow baru per detik, rata-rata 15 span per workflow, dan 700 byte per span yang dienkode sebelum kompresi penyimpanan. Trace yang disimpan harus dapat dicari dalam waktu 30 detik pada p99. Pencarian eksak berdasarkan tenant dan ID trace harus selesai dalam waktu 2 detik pada p99; pencarian umum berdasarkan layanan, operasi, error, durasi, dan rentang waktu harus selesai dalam waktu 3 detik pada p95. Instrumentasi tidak boleh menunggu platform pusat secara sinkron, dan kehilangan satu availability zone tidak boleh menghentikan aplikasi dalam memancarkan telemetri.

Platform membuat atau menerima span, menyebarkan konteks trace W3C melalui transport yang didukung, merakit span yang tiba terlambat atau tidak berurutan, mengambil sampel seluruh trace di bawah anggaran eksplisit, menyimpan detail trace, dan mendukung grafik dependensi yang diturunkan dari trace yang disimpan. Membangun SDK untuk setiap bahasa, UI APM lengkap, penyimpanan log, penyimpanan metrik, dan deteksi anomali berada di luar cakupan. Log dan metrik dapat membawa ID trace atau exemplar, tetapi keduanya tetap merupakan sistem yang terpisah.

Tiga halaman persiapan wawancara tahun 2026 yang independen menyajikan distributed tracing sebagai latihan desain sistem yang mencakup span, propagasi konteks, perakitan trace, sampling, dan penyimpanan kueri. Hal tersebut menetapkan representasi saat ini tanpa membuktikan atribusi perusahaan mana pun, sehingga artikel ini tidak mencantumkannya. Model teknis berasal dari rekomendasi W3C Trace Context, spesifikasi OpenTelemetry dan implementasi Collector, serta makalah Dapper dari Google.

Apa yang Dievaluasi oleh Pewawancara

Sinyal pertama adalah apakah kandidat menjaga kausalitas di seluruh batas proses. trace_id saja tidak cukup. Setiap operasi membutuhkan span_id, relasi induk (parent) atau tautan eksplisit, pengaturan waktu (timing), status, identitas sumber daya, dan atribut yang dibatasi dengan cermat. Format W3C mendefinisikan traceparent yang dapat diinteroperasikan dan status vendor opsional di tracestate; format ini tidak menjadikan ID trace masuk yang tidak tepercaya sebagai kredensial otorisasi. Jawaban yang kuat memvalidasi konteks yang masuk, memisahkan tenant pada saat penyerapan, dan mendefinisikan perilaku pada batas kepercayaan.

Sinyal kedua adalah model sampling yang realistis. Head sampling mengambil keputusan sebelum seluruh trace diketahui dan dapat mengurangi beban kerja SDK, jaringan, dan penyerapan. Ini tidak dapat menjamin penyimpanan setiap error yang terjadi belakangan. Tail sampling dapat memilih trace setelah melihat sebagian besar span, tetapi harus menerima dan menampung span tersebut terlebih dahulu. Ini mengurangi penyimpanan downstream, bukan biaya pengumpulan upstream. Jika head sampler 2% telah membuang trace, tail sampler berikutnya tidak akan dapat memulihkan span error-nya.

Sinyal ketiga adalah perakitan trace alih-alih pipeline event generik. Span dapat terduplikasi, tertunda, dan tidak berurutan; fan-out asinkron atau pemrosesan batch dapat membentuk directed acyclic graph (DAG) alih-alih struktur pohon yang rapi. Tail sampler memerlukan semua span untuk satu trace dialihkan ke pemilik keputusan yang sama, aturan penyelesaian yang terbatas, perlindungan memori, dan penanganan span yang terlambat secara eksplisit. Batasan stateful inilah yang menentukan apakah desain menghasilkan bukti yang berguna atau bias sampling tersembunyi.

Sinyal terakhir adalah operabilitas. Jawaban yang baik menguantifikasi volume mentah dan yang disimpan, membatasi indeks atribut sembarang, mengisolasi tenant yang bising, mengukur propagasi yang hilang dan span yang dibuang, serta mencegah jalur telemetri menjadi dependensi aplikasi. Diagram yang hanya berakhir pada "menulis span ke database" membiarkan pertanyaan tentang biaya, kebenaran, dan kegagalan tidak terjawab.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Alur kerja mana yang memerlukan keputusan tail? Tail sampling penuh memerlukan penerimaan terpusat dari semua span kandidat. Desain ini menggunakan source head sampling untuk lalu lintas biasa dan mengirimkan set rute kritis yang terkontrol pada 100% ke tail pool. Jika setiap rute memerlukan retensi yang sadar-error (error-aware), seluruh stream mentah harus sesuai dengan anggaran jaringan dan status pusat.
• Apa yang dimaksud dengan "trace lengkap"? Tidak ada penanda akhir universal di seluruh antrean dan pekerjaan yang terpisah. Untuk permintaan sinkron, root span yang selesai ditambah grace interval sangat berguna. Alur kerja yang berjalan lama memerlukan kebijakan yang lebih panjang atau penyelesaian alur kerja yang eksplisit. Platform harus tetap mempublikasikan flag incomplete alih-alih mengklaim kepastian.
• Pencarian mana yang bersifat kontraktual? Pencarian ID trace secara eksak dan filter terbatas pada layanan, operasi, status, bucket durasi, dan waktu termasuk dalam cakupan. Predikat teks lengkap sembarang pada setiap atribut akan melipatgandakan biaya indeks dan menciptakan penyalahgunaan kardinalitas tinggi, sehingga atribut non-allowlist hanya tersedia setelah trace diambil.
• Berapa lama data disimpan? Kebijakan yang diasumsikan adalah tujuh hari data hot terindeks dan 23 hari data objek terkompresi lainnya. Retensi hot yang lebih lama mengubah ukuran penyimpanan dan indeks; aturan penghapusan hukum juga menentukan apakah kunci objek dan domain enkripsi harus spesifik untuk setiap tenant.
• Apakah trace lintas tenant diizinkan? Standarnya adalah tidak. Gateway mengikat kredensial yang diautentikasi ke suatu tenant dan menimpa bidang tenant apa pun yang disediakan dalam span. Alur kerja lintas domain yang disetujui menggunakan tautan eksplisit atau korelasi yang diotorisasi secara terpisah, tidak pernah menggunakan pengidentifikasi tenant yang dipilih klien.
• Bagaimana kausalitas asinkron harus direpresentasikan? Satu induk berfungsi untuk satu pendahulu kausal. Konsumen batch dan fan-in dapat bergantung pada banyak produsen, sehingga mereka membutuhkan tautan span (span links). Memaksakan satu induk akan menghilangkan informasi; menyalin satu span di bawah banyak induk merusak penghitungan trace.
• Apa yang boleh hilang dari aplikasi saat kelebihan beban (overload)? Lalu lintas bisnis harus tetap berjalan. Antrean lokal terbatas dapat membuang telemetri setelah menghabiskan anggaran memori dan disk, tetapi kehilangan tersebut dihitung berdasarkan layanan, tenant, alasan, dan kelas sampling. Jika kehilangan telemetri nol diperlukan, tracing menjadi dependensi jalur bisnis dan kontrak ketersediaan harus diubah.

Kerangka Jawaban 30 Detik

"Saya akan memisahkan propagasi konteks, pengumpulan, keputusan trace, dan penyimpanan kueri. Pustaka terinstrumentasi membuat span dan menyebarkan konteks W3C yang tervalidasi. Agen lokal mengelompokkannya secara asinkron dan menggunakan spool terbatas, sehingga platform pusat tidak pernah memblokir jalur permintaan. Gateway regional mengautentikasi tenant, menegakkan skema dan kuota, serta menambahkan span ke stream persisten yang dipartisi berdasarkan ID trace.

"Rute biasa menggunakan head sampling yang konsisten untuk mengurangi biaya upstream. Rute kritis masuk ke tail pool penuh; semua span untuk satu trace mencapai satu assembler, yang menunggu root ditambah grace window, menerapkan anggaran error, latensi, dan baseline, serta mencatat apakah trace tidak lengkap. Trace yang disimpan masuk ke object store untuk detail kanonikal dan ke hot index yang masuk allowlist untuk pencarian ID trace dan filter terbatas. Saya akan mengukur status pra-sampling dan penyimpanan yang disimpan, melakukan degradasi dengan membuang trace normal berprioritas rendah terlebih dahulu, dan memverifikasi propagasi, span yang terlambat, sampling yang bias, isolasi tenant, serta pemulihan zona dengan canary trace."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Tentukan kontrak span dan API kueri.

Catatan span minimal berisi:

Span {
  tenant_id, trace_id, span_id, parent_span_id?, links[],
  service, operation, kind, start_time, end_time, status,
  resource_attributes, span_attributes, events[],
  observed_at, schema_version, trace_flags, tracestate?
}

Gateway menurunkan tenant_id dari autentikasi. Ini memvalidasi panjang dan format pengidentifikasi, menolak catatan berukuran terlalu besar, menormalkan bidang semantik yang disetujui, dan membatasi jumlah atribut, panjang nilai, jumlah event, jumlah tautan, dan total byte. Ini menyimpan waktu event dan observed_at: jam layanan membantu merender garis waktu, sementara waktu kolektor mengungkap masalah penundaan dan clock skew. SDK harus mengukur durasi span lokal dengan monotonic clock meskipun pengurutan lintas host masih memerlukan wall time dan edge kausal.

Kontrak kueri utama adalah:

GetTrace(tenant_id, trace_id)
SearchTraces(tenant_id, start, end, service?, operation?, status?,
             min_duration?, max_duration?, cursor?, limit?)

GetTrace mengembalikan span, tautan, kebijakan dan versi sampling, first_observed_at, last_observed_at, dan peringatan kelengkapan. SearchTraces memerlukan rentang waktu terbatas dan mengembalikan kursor alih-alih offset tak terbatas. Pengambilan detail dan pencarian sekunder adalah jalur akses yang berbeda; satu rekaman trace yang lebar tidak boleh diduplikasi ke setiap indeks sekunder.

Langkah 2: Sebarkan konteks tanpa menjadikannya celah kepercayaan.

Untuk HTTP, SDK mengekstrak dan menyuntikkan W3C traceparent, yang membawa versi, ID trace, ID induk, dan flag; tracestate membawa status opsional khusus vendor. Produsen pesan menempatkan bidang propagasi yang sama dalam metadata pesan. Penerima memvalidasi format sebelum bergabung dengan trace. Konteks yang tidak valid akan memulai trace baru dan meningkatkan penghitung error propagasi alih-alih merusak key space yang ada.

Pada batas yang menghadap Internet atau lintas tenant, layanan dapat dengan sengaja memulai trace baru dan melampirkan tautan ke konteks upstream yang disetujui. Ini mempertahankan korelasi tanpa membiarkan pemanggil eksternal memilih induk internal atau kontrol sampling. Baggage adalah mekanisme key-value terpropagasi yang terpisah. Baggage harus masuk allowlist, dibatasi ukurannya, dan dibersihkan dari rahasia atau data pribadi karena disebarkan ke setiap hop downstream.

Otomatiskan instrumentasi pustaka HTTP, RPC, database, dan antrean umum terlebih dahulu. Dapper menunjukkan mengapa instrumentasi pustaka umum meningkatkan cakupan dengan upaya aplikasi yang lebih rendah. Custom span tetap berguna untuk batasan bisnis, tetapi platform mengukur layanan dan rute yang kekurangan span server atau klien yang diharapkan. Kualitas trace hanya selengkap instrumentasi dan sampel yang dipertahankan.

Langkah 3: Jauhkan pengumpulan dari jalur permintaan aplikasi.

Span yang selesai masuk ke buffer terbatas dalam proses dan di-flush dalam batch terkompresi ke agen node atau sidecar. Agen memiliki spool disk terbatas untuk pemadaman kolektor singkat, percobaan ulang eksponensial dengan jitter, dan antrean per prioritas. Agen tidak pernah menunggu secara sinkron untuk pengakuan (acknowledgement) pusat sebelum aplikasi dapat menyelesaikan responsnya. Setelah anggaran lokal habis, agen membuang telemetri normal berprioritas rendah terlebih dahulu dan mengekspor counter yang menjelaskan secara tepat apa yang hilang.

Gateway stateless regional mengautentikasi agen, mengikat tenant, menegakkan kuota byte dan span, memvalidasi skema, dan menambahkan batch yang diterima ke stream persisten yang direplikasi. Pengakuan berarti stream regional telah menerima batch secara persisten, bukan berarti pencarian telah memuatnya. Konsumen bersifat idempoten berdasarkan (tenant_id, trace_id, span_id) ditambah versi catatan; pengiriman duplikat memperbarui metadata observasi tetapi tidak menduplikasi span.

Stream mempartisi berdasarkan hash stabil dari (tenant_id, trace_id). Hal tersebut memberi satu trace pemilik keputusan yang berurutan tanpa memerlukan urutan span global. Untuk tail sampling pada skala yang lebih besar, lapisan kolektor pertama dapat membagi beban (load-balance) berdasarkan ID trace ke lapisan stateful kedua. OpenTelemetry Collector mendokumentasikan invarian yang sama: semua span untuk satu trace harus mencapai instance tail-sampling yang sama.

Langkah 4: Buat setiap batasan kapasitas dapat dihitung ulang.

Sebelum sampling, beban kerja menghasilkan:

500,000 workflows/s × 15 spans/workflow = 7,500,000 spans/s
7,500,000 spans/s × 700 bytes/span = 5.25 GB/s
5.25 GB/s × 86,400 s = 453.6 TB/day raw

Ini adalah asumsi beban kerja, bukan klaim kompresi yang terukur. Platform yang mengirimkan semua span mentah ke tail sampler pusat harus menyediakan jalur penyerapan 5,25 GB/s sebelum memperhitungkan replikasi, overhead protokol, percobaan ulang, skew, dan ruang failover.

Asumsikan rute biasa menghasilkan 90% span dan menggunakan head sampling konsisten sebesar 2%. Rute kritis menghasilkan 10% dan masuk ke tail pool pada 100%:

ordinary: 7.5M × 90% × 2% = 135,000 spans/s
tail pool input: 7.5M × 10% = 750,000 spans/s
collector input: 885,000 spans/s × 700 bytes = 619.5 MB/s

Jika kebijakan tail mempertahankan rata-rata 10% dari span kandidatnya, penyimpanan hot menerima 135,000 + 75,000 = 210,000 spans/s, atau 147 MB/s dan 12,7008 TB/hari sebelum kompresi, replikasi, indeks, dan metadata objek. Tujuh hari hot setara mentah adalah 88,9056 TB. Tolok ukur (benchmark) dengan distribusi atribut produksi menentukan kompresi dan jumlah node; perhitungan aritmatika hanya menetapkan batas bawah dan menunjukkan batas sampling mana yang membayar biaya mana.

Langkah 5: Perlakukan tail sampling sebagai bottleneck stateful yang menentukan.

Assembler menyimpan status parsial yang dikunci oleh tenant dan ID trace: span unik, waktu mulai paling awal, akhir terbaru, status penyelesaian root, status error, durasi saat ini, jumlah byte, dan kedatangan terakhir. Trace sinkron memenuhi syarat untuk keputusan setelah root-nya berakhir dan grace interval berlalu. Keputusan juga dipaksakan pada usia maksimum, jumlah span, atau jumlah byte. Alur kerja yang panjang menggunakan kebijakan terpisah; jika tidak, satu trace dapat menahan memori tanpa batas.

Urutan keputusan mencadangkan kapasitas untuk alur kritis eksplisit, error, dan trace dengan latensi tinggi, kemudian menggunakan baseline probabilistik yang konsisten dalam anggaran per layanan dan per tenant. Aturan global "simpan setiap error" bukanlah kebijakan yang terbatas selama insiden, ketika error dapat mendekati 100%. Token bucket dan batas atas byte membatasi setiap kelas; respons terhadap kehabisan kapasitas adalah kebijakan terdegradasi yang terlihat, bukan crash karena kehabisan memori.

Sampler mencatat cache keputusan untuk span yang terlambat. Span yang terlambat untuk trace yang disimpan akan ditambahkan dan menandai trace telah diperbarui. Span yang terlambat untuk trace yang dibuang akan disingkirkan secara konsisten. Span yang tiba setelah cache kedaluwarsa dihitung sebagai yatim (orphaned); itu tidak boleh membuat trace satu span yang menyesatkan. Setiap trace yang disimpan membawa complete, decision_reason, dan penghitung span yang terlambat. Meningkatkan grace interval akan meningkatkan kelengkapan tetapi meningkatkan memori, latensi keputusan, dan jumlah trace yang rentan terhadap kegagalan sampler.

Jebakan kritis adalah pipeline hibrida. Logika tail hanya dapat memilih di antara trace yang mencapainya. Jika head sampler 2% membuang trace normal sebelum error terjadi di hilir, tahap tail tidak dapat memulihkannya. Oleh karena itu, rute yang memerlukan keputusan sadar-error yang terjamin harus masuk ke tail pool tanpa keputusan pembuangan di hulu, atau menggunakan pemicu terpisah dan menerima bahwa itu tidak akan merekonstruksi masa lalu.

Langkah 6: Simpan detail kanonikal secara terpisah dari indeks terbatas.

Span yang disimpan dipadatkan menjadi objek terkompresi dan tidak dapat diubah (immutable) yang dipartisi berdasarkan tenant dan waktu, dengan manifes untuk setiap revisi trace. Direktori ID trace memetakan (tenant_id, trace_id) ke lokasi objek dan revisi terbaru. Jalur ini melayani pencarian eksak. Objek trace terbaru dapat di-cache, tetapi lapisan objek adalah sumber pembangunan kembali untuk indeks turunan.

Hot search index menyimpan satu baris ringkasan per trace: tenant, ID trace, root service dan operasi, bucket mulai, durasi, status, kumpulan layanan terpilih atau sidik jari, alasan sampling, kelengkapan, dan penunjuk objek. Hanya bidang yang masuk allowlist yang menerima indeks sekunder. ID pengguna, teks SQL, URL, dan nilai baggage sembarang tetap berada dalam detail yang dilindungi atau disunting; mengindeksnya secara default akan menciptakan kardinalitas tak terbatas, paparan privasi, dan amplifikasi penulisan.

Tampilan dependensi layanan dan latensi adalah agregat streaming atas trace yang disimpan dan harus diberi label sebagai perkiraan sampel. Bobot sampling dapat mendukung beberapa perkiraan hitungan yang tidak bias ketika probabilitas diketahui, tetapi sampel tail yang bias terhadap error dan latensi tidak secara otomatis mewakili proporsi lalu lintas. Metrik tetap menjadi sumber untuk tingkat armada yang tepat; trace menjelaskan jalur kausal individual.

Langkah 7: Isolasi tenant dan tentukan perilaku kegagalan.

Gateway memberlakukan byte per detik, span per detik, trace parsial konkuren, konkurensi kueri, dan byte yang dipertahankan per tenant. Kunci partisi menyertakan identitas tenant, kebijakan enkripsi dapat memisahkan tenant yang diatur regulasi, dan otorisasi kueri diperiksa sebelum pencarian indeks apa pun. Satu tenant dengan trace besar atau atribut berkardinalitas tinggi tidak boleh mengeluarkan (evict) status sampler tenant lain.

Jika gateway atau availability zone gagal, agen akan mencoba lagi ke endpoint regional lain dan menggunakan spool terbatas mereka. Jika stream persisten lambat, kontrol penerimaan menurunkan sampling biasa dan menolak kelebihan byte sebelum perakitan stateful. Jika assembler mati, stream memutar ulang partisinya; checkpoint mempercepat pemulihan, sementara kunci span idempoten menyerap duplikat. Selama pemadaman indeks, objek kanonikal terus mendarat dan backlog indeks bertambah. Kueri yang baru ditulis dan bersifat eksak dapat melaporkan "diterima, sedang diindeks" alih-alih mengembalikan not-found palsu.

Jika tail pool kelebihan beban, kurangi baseline probabilistik secara progresif, batasi trace besar, lalu kembali ke kebijakan head deterministik untuk rute yang terpengaruh. Pertahankan canary trace control-plane dan beberapa kapasitas error yang terbatas. Pantau span yang diterima, dibuang, dicoba lagi, dikeluarkan terlalu dini, terlambat, yatim, dan diindeks berdasarkan tenant, layanan, zona, dan kebijakan.

Langkah 8: Verifikasi kebenaran, bukan hanya throughput.

Pengujian propagasi mencakup header yang valid, hilang, salah format, dan versi masa depan; batasan lintas tenant dan Internet; batas baggage; antrean; percobaan ulang; fan-out; fan-in; dan tautan batch. Pengujian perakitan menyuntikkan trace duplikat, tidak berurutan, induk hilang, terlambat, berukuran besar, dan tidak pernah selesai. Pengujian sampling membuktikan konsistensi seluruh trace, batas anggaran, keputusan probabilitas deterministik, kebijakan error dan latensi, serta fakta bahwa pembuangan head di hulu tetap tidak dapat dipulihkan.

Pengujian beban mempertahankan ukuran trace dan ketimpangan (skew) tenant seperti di produksi. Pengujian ini mengukur overhead SDK, kehilangan pada agen, penerimaan gateway, jeda stream, memori trace aktif, latensi keputusan, byte yang disimpan, jeda indeks, pencarian trace, dan pencarian berfilter. Pengujian kegagalan menghapus zona, memulai ulang assembler selama partisi hot, menjeda penyimpanan objek, menghabiskan kuota tenant, dan membangun kembali indeks hot dari objek kanonikal.

Pancarkan alur kerja canary sintetis secara terus-menerus dengan grafik yang diketahui melalui setiap wilayah. Berikan peringatan jika span yang diharapkan hilang, relasi induk berubah, kesegaran pencarian melanggar 30 detik, atau pencarian ID trace melanggar SLO-nya. Proses kolektor yang sehat tidak membuktikan bahwa trace lengkap atau dapat dicari.

Contoh Jawaban yang Kuat

"Pertama-tama saya akan menyatakan bahwa trace adalah grafik kausal dari span, bukan sekadar kumpulan baris log. Setiap span memiliki ID trace yang terikat tenant, ID span, induk atau tautan, waktu, status, sumber daya, atribut terbatas, event, dan waktu observasi. Layanan menyebarkan konteks W3C yang tervalidasi melalui HTTP atau metadata pesan. Pada batas yang tidak tepercaya, saya akan memulai trace internal baru dan menautkannya, karena konteks trace adalah data korelasi, bukan otorisasi.

"Span meninggalkan jalur permintaan melalui buffer dalam proses yang terbatas dan agen lokal. Agen mengelompokkan, mengompresi, menyimpan sementara ke disk, dan membuang data berprioritas rendah yang terukur daripada memblokir lalu lintas bisnis. Gateway regional mengautentikasi tenant, menegakkan skema dan kuota, serta menulis ke stream yang direplikasi. Mempartisi berdasarkan tenant dan ID trace mengirimkan setiap trace ke satu assembler dan membuat percobaan ulang menjadi idempoten berdasarkan ID span.

"Beban kerja mentah adalah 7,5 juta span per detik dan 5,25 GB/s. Saya tidak akan mengirimkan semua itu ke tail sampler secara ceroboh. Rute biasa menggunakan head sampling konsisten 2%. Pool rute kritis 10% yang terkontrol masuk ke tail sampling pada 100%, sehingga input kolektor adalah 885.000 span/detik, atau 619,5 MB/s. Jika tail pool mempertahankan 10%, penyimpanan menerima 210.000 span/detik, sekitar 12,7 TB/hari mentah sebelum indeks dan replika. Batasan tersebut adalah input tolok ukur, bukan hasil kompresi yang dijanjikan.

"Assembler adalah bagian yang sulit. Bagian ini menampung trace parsial, menunggu root selesai ditambah grace window, dan memaksakan keputusan pada batas usia, span, dan byte. Ini mencadangkan kapasitas terbatas untuk trace kritis, error, dan lambat, lalu mengisi anggaran per layanan dengan baseline yang konsisten. Ini menyimpan cache keputusan untuk span yang terlambat dan memberi label trace yang tidak lengkap. Pembuangan head 2% di hulu tidak dapat dipulihkan nanti, jadi setiap rute yang benar-benar membutuhkan retensi sadar-error harus masuk ke tail pool tanpa disampling.

"Detail trace yang disimpan masuk ke penyimpanan objek terkompresi dengan direktori ID trace. Indeks hot terpisah menyimpan satu ringkasan trace dan hanya bidang layanan, operasi, status, durasi, dan waktu yang masuk allowlist. Hal tersebut mengontrol kardinalitas dan memungkinkan indeks dibangun kembali. Selama kegagalan, agen menggunakan spool terbatas, partisi stream diputar ulang, penulisan objek berlanjut jika pencarian mati, dan beban berlebih memangkas baseline normal sebelum kelas yang dilindungi. Saya akan memverifikasi batasan konteks, span duplikat dan terlambat, bias dan batas sampling, isolasi tenant yang bising, kehilangan zona, pembangunan kembali, dan trace canary menyeluruh."

Kesalahan Umum

• Mengatakan "sample 2%, lalu simpan setiap error di tail" → tahap pertama telah menghapus 98% trace kandidat, termasuk error berikutnya → kirim rute yang dilindungi tanpa sampling ke tail pool atau lemahkan jaminannya.
• Melakukan hashing span di seluruh kolektor tanpa ID trace → satu tail sampler hanya melihat fragmen dan membuat keputusan yang bias → arahkan setiap span untuk (tenant, trace_id) ke pemilik keputusan yang sama.
• Menunggu selamanya untuk trace lengkap → pekerjaan asinkron tidak memiliki penanda akhir universal, sehingga status tumbuh tanpa batas → gunakan root-plus-grace, usia/ukuran maksimum, kebijakan alur kerja eksplisit, dan flag tidak lengkap.
• Memperlakukan traceparent sebagai identitas atau otorisasi → pemanggil eksternal dapat memilih bidang korelasi → autentikasi tenant secara independen dan mulai trace baru yang ditautkan pada batas kepercayaan.
• Memasukkan baggage atau atribut sembarang ke dalam setiap indeks → kardinalitas, amplifikasi penulisan, dan paparan data sensitif menjadi tidak terbatas → masukkan bidang yang diindeks ke dalam allowlist dan batasi atau redaksi nilai yang dipropagasi.
• Mengirim span secara sinkron ke kolektor pusat → kegagalan telemetri meningkatkan latensi aplikasi atau risiko ketersediaan → kumpulkan secara asinkron melalui antrean lokal terbatas dan ekspos metrik kehilangan.
• Menyimpan setiap span tetapi menghilangkan ringkasan trace → pencarian layanan, durasi, dan error memindai data detail yang sangat besar → simpan detail kanonikal ditambah satu baris ringkasan terbatas yang dapat dibangun kembali per trace.
• Menyebut sampel tail yang bias sebagai distribusi lalu lintas eksak → aturan error dan latensi sengaja merepresentasikan trace yang tidak biasa secara berlebihan → publikasikan metadata sampling dan gunakan metrik untuk tingkat agregat yang tepat.
• Hanya menguji uptime kolektor → putusnya konteks, span yang hilang, dan jeda indeks dapat tetap tidak terlihat → jalankan canary dengan grafik yang diketahui dan pastikan kelengkapan, sampling, kesegaran, dan SLO kueri.

Pertanyaan Lanjutan dan Jawaban

Lanjutan 1: Produk sekarang membutuhkan setiap trace error sambil mempertahankan anggaran penyerapan pusat yang sama. Apa yang berubah?

Kedua persyaratan tersebut mungkin bertentangan. Error sering kali diketahui hanya setelah span hilir dieksekusi, sehingga source head sampler tidak dapat menjamin retensi. Kuantifikasi tingkat span mentah maksimum dan kapasitas tail pusat. Jika anggaran tidak dapat menerima semua rute kandidat, persempit jaminan ke kumpulan rute kritis yang terbatas, tingkatkan kapasitas, atau tambahkan pemicu error aplikasi yang memulai sampling tingkat tinggi di masa mendatang sambil mengakui bahwa span yang dibuang sebelumnya tidak dapat direkonstruksi. "Selalu simpan error" juga harus memiliki batas byte karena insiden dapat mengubah hampir semua lalu lintas menjadi error.

Lanjutan 2: Sebuah pesan mengonsumsi event dari 10 trace produsen. Induk mana yang harus digunakan oleh span konsumen?

Tidak ada induk tunggal yang mewakili sepuluh penyebab independen. Buat span konsumen atau pemrosesan batch dalam alur kerja yang sesuai dan lampirkan tautan ke sepuluh konteks produsen, dengan tunduk pada batas jumlah tautan. Jika batch itu sendiri memiliki satu konteks pengiriman, itu bisa menjadi induk sementara input individual tetap menjadi tautan. Kode kueri dan visualisasi harus mendukung DAG dan menampilkan metadata tautan yang terpotong; menyalin span konsumen ke dalam sepuluh pohon akan mendistorsi durasi dan penyimpanan.

Lanjutan 3: Tail sampler mengeluarkan trace parsial sebelum jendela keputusannya. Bagaimana Anda men-debug-nya?

Bandingkan jumlah trace aktif dan byte, distribusi ukuran trace, keterlambatan kedatangan, partisi hot, usia keputusan, counter pengeluaran dini, dan ketimpangan per tenant. Meningkatkan jendela tunggu dapat memperburuk tekanan memori. Pertama, batasi trace yang terlalu besar, isolasi tenant yang bising, bagi partisi tanpa merusak afinitas trace, dan kurangi baseline normal. Kemudian tambahkan kapasitas atau persingkat jendela berdasarkan nilai span terlambat yang diamati. Jalankan kebijakan bayangan (shadow policy) untuk mengukur bagaimana perubahan yang diusulkan mengubah retensi error, trace lambat, dan kelengkapan.

Lanjutan 4: Pencarian mati selama dua jam, tetapi penyerapan dan penyimpanan objek sehat. Apa yang dikembalikan API?

Lanjutkan penulisan objek trace kanonikal dan backlog perubahan indeks yang persisten. GetTrace dapat menggunakan direktori ID trace jika jalur tersebut tetap tersedia; pencarian sekunder melaporkan data as_of yang usang atau status sementara-tidak-tersedia yang eksplisit. API tidak boleh melaporkan bahwa trace yang baru diterima tidak ada hanya karena ringkasannya belum diindeks. Setelah pemulihan, putar ulang secara idempoten, bandingkan hitungan dan jeda, dan bangun kembali indeks dari objek jika backlog rusak.

Lanjutan 5: Bagaimana Anda membuktikan bahwa sampling tidak menyembunyikan satu layanan bervolume rendah sepenuhnya?

Pertahankan anggaran baseline minimum per layanan atau per operasi sebelum membagikan sisa anggaran global. Lacak probabilitas dan alasan keputusan dengan setiap trace yang disimpan, dan berikan peringatan pada layanan yang memiliki lalu lintas tetapi tidak ada trace yang dipertahankan. Canary sintetis memverifikasi jalur penuh secara independen dari probabilitas. Bandingkan cakupan yang diturunkan dari trace dengan hitungan permintaan metrik; jika layanan menerima permintaan tetapi tidak menghasilkan span, bedakan antara instrumentasi yang hilang, kegagalan propagasi, pembuangan kuota, keputusan head, keputusan tail, dan kehilangan indeks.