Perintah dan konteks
Sebuah worker mengonsumsi 100 event dari sebuah antrean dan membuat satu panggilan API downstream setelah agregasi. Setiap event dapat menjadi milik Trace yang berbeda, dan worker juga dapat dipicu oleh scheduler atau replay. Modelkan trace sedemikian rupa sehingga setiap sumber tetap dapat ditemukan tanpa berpura-pura bahwa permintaan yang tidak terkait membentuk satu hierarki parent-child.
OpenTelemetry mendeskripsikan Span sebagai operasi yang dapat membentuk sebuah hierarki dan memungkinkan setiap Span berisi nol atau lebih Link. Gambaran umumnya menyebutkan pemrosesan batch yang diinisiasi oleh beberapa Span yang masuk sebagai use case umum untuk Links.
Hal yang sedang diuji oleh pewawancara
Kandidat harus memahami bahwa parent adalah satu konteks saat ini, sedangkan Link merepresentasikan kausalitas terkait tanpa hubungan parentage. Mereka harus mampu mengontrol jumlah link, sampling, dan atribut dengan kardinalitas tinggi, sembari mempertahankan korelasi metrik dan log yang berguna.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
- Apakah sebuah batch dapat berisi beberapa tenant, tingkat keamanan, atau tipe bisnis yang berbeda?
- Apakah panggilan downstream merupakan satu operasi agregat, atau dapat tetap dilakukan per-event?
- Apakah tujuannya adalah akuntabilitas per-event, analisis latensi, atau throughput batch?
- Apakah sampling diputuskan di ingress, atau dapatkah worker mempertahankan konteks sumber yang dipilih?
- Apakah atribut Link boleh berisi ID event, ID tenant, atau field sensitif?
Kerangka jawaban 30 detik
“Span pemrosesan batch menggunakan konteks worker atau scheduler sebagai parent-nya. 100 SpanContext yang masuk menjadi Links karena mereka secara bersama-sama menyebabkan satu operasi batch tanpa membentuk satu rantai parent-child. Saya hanya menyimpan atribut ber-kardinalitas rendah yang diperlukan, menerapkan batasan link, dan menghitung pemotongan (truncation). Metrik batch mencakup ukuran, waktu tunggu antrean, pemrosesan, latensi downstream, kegagalan, dan percobaan ulang (retry); log dikorelasikan dengan ID batch dan hash event. Field tenant yang sensitif difilter, serta batch yang gagal atau di-replay memiliki jalur pengamanan sampling.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Pisahkan parent dari Link
Parent menentukan satu Span mana yang dilanjutkan oleh operasi saat ini, membentuk pohon Trace dan mewarisi TraceId-nya. Link mencatat satu SpanContext terkait dari Trace yang sama atau Trace lain. Ketika sumber-sumber berstatus setara (peer) dalam sebuah batch, memilih event pertama sebagai parent akan menciptakan hierarki yang salah.
Batch-processing Span
parent: worker / scheduler context
links: event-1 SpanContext ... event-100 SpanContextLangkah 2: Pertahankan SpanContext melintasi batas
Ekstrak TraceContext dari header pesan, validasi format serta flag sampling-nya, lalu buat Link. Jangan memasukkan seluruh pesan, input pengguna, atau token mentah ke dalam atribut Link. Untuk konteks yang hilang, catat sebagai “tidak ada konteks sumber” alih-alih mengarang TraceId baru.
Langkah 3: Batasi ukuran dan biaya link
Seratus link hanyalah batas contoh; batch produksi bisa jauh lebih besar. Konfigurasikan batas jumlah link pada SDK atau pembatasan aplikasi, pertahankan representasi sumber error, retry, replay, atau tenant prioritas, dan catat jumlah link yang di-drop. Pemotongan harus terlihat dalam metrik dan log batch.
Langkah 4: Tentukan siklus hidup Span batch
Span mencakup waktu tunggu batch, deserialisasi, agregasi, panggilan downstream, dan commit. Tambahkan event fase atau metrik. Setiap Span yang dibuat harus diakhiri saat sukses, gagal, pembatalan, atau commit parsial. Satu event yang lambat tidak boleh menyembunyikan batas fase batch.
Langkah 5: Buat sampling dan kegagalan dapat didiagnosis
Sampling ingress dapat membuang Trace sumber, sehingga worker memerlukan kebijakan keamanan untuk kegagalan, retry, dead letter, dan replay manual. Links yang ada saat pembuatan Span dapat memengaruhi sampling; Links yang ditambahkan kemudian mungkin tidak memengaruhinya. Buat urutan dan fallback tersebut eksplisit.
Langkah 6: Berikan tugas berbeda untuk trace, metrik, dan log
Traces menjelaskan kausalitas satu batch. Metrik memuat ukuran batch, waktu tunggu antrean, latensi pemrosesan, sukses/gagal, dan pemotongan. Log menggunakan ID batch, hash event, dan ID replay untuk menemukan sampel yang terkontrol. Jangan gunakan ID event sebagai label metrik tanpa batas.
Langkah 7: Isolasi tenant dan privasi
Untuk batch multi-tenant, gunakan hash yang tidak dapat dibalik (irreversible) atau referensi internal pada Links dan log, serta filter atribut sebelum diekspor. Jika tingkat keamanan tidak boleh dicampur, pisahkan batch berdasarkan tenant atau izin sehingga pembaca dengan hak akses rendah tidak dapat menelusuri konteks tenant lain.
Langkah 8: Verifikasi kueri dan kegagalan
Uji satu sumber, Traces campuran, konteks yang hilang, overflow link, kehilangan akibat sampling, retry downstream, kegagalan parsial, dead letter, dan replay. Verifikasi bahwa Span batch melompat ke Trace sumber yang dipertahankan dan metrik dapat mengidentifikasi batch yang dipotong atau tidak di-sample.
Model jawaban berkualitas tinggi
“Span batch menggunakan worker atau scheduler sebagai parent, dan setiap SpanContext pesan adalah Link. Hal itu mempertahankan fakta bahwa 100 event secara bersama-sama menyebabkan satu panggilan downstream tanpa mengarang hierarki parent-child. Saya membatasi link dan menghitung yang di-drop, memfilter atribut tenant dan atribut sensitif, serta menggunakan metrik untuk ukuran batch, waktu tunggu antrean, latensi downstream, kegagalan, dan retry. Log dikorelasikan dengan ID batch dan replay, serta batch yang gagal mendapatkan perlindungan sampling. Pengujian mencakup konteks yang hilang, Traces campuran, overflow, dan replay.”
Kesalahan umum
- Memilih pesan pertama sebagai parent → kausalitas palsu → gunakan parent worker bersama dan Links untuk sumber-sumbernya.
- Memasukkan pesan lengkap ke dalam Link → kebocoran privasi dan biaya → hanya simpan field yang telah disanitasi dan ber-kardinalitas rendah yang diperlukan.
- Menambahkan Links tanpa batas → Span dan biaya ekspor tidak terbatas → batasi dan ukur pemotongan.
- Mengakhiri Span hanya saat sukses → kegagalan dan pembatalan meninggalkan Span terbuka → akhiri dalam blok finally atau scope.
- Menggunakan ID event sebagai label metrik → ledakan kardinalitas → simpan detail dalam log atau trace.
- Mengasumsikan Links yang terlambat selalu memengaruhi sampling → sumber penting menghilang → siapkan konteks sampling sebelum pembuatan Span.
Pertanyaan lanjutan dan respons yang kuat
Pertanyaan lanjutan 1: Apakah batch satu pesan memerlukan Link?
Batch tersebut dapat menggunakan konteks pesan tersebut sebagai parent. Jika worker memiliki masa pakai (lifetime) independen, parent worker ditambah satu Link juga valid; pilih berdasarkan apakah batch tersebut merupakan operasi turunan (child) langsung.
Pertanyaan lanjutan 2: Apakah Links menggabungkan Trace yang berbeda?
Tidak. Links mengekspresikan keterkaitan dan mempertahankan masing-masing TraceId. Sistem kueri harus menyediakan navigasi dari Link ke Trace sumber.
Pertanyaan lanjutan 3: Sumber mana yang bertahan dari pemotongan (truncation)?
Prioritaskan error, retry, replay, tenant prioritas, atau sampel deterministik; catat jumlah total dan jumlah yang di-drop. Menyimpan N pertama secara diam-diam akan menimbulkan bias.
Pertanyaan lanjutan 4: Bagaimana cara mendiagnosis batch yang gagal?
Berikan ID batch/replay independen pada kegagalan dan replay dead-letter, pertahankan Links sumber error atau ringkasan yang terkontrol, dan sertakan tipe kegagalan dalam metrik.
Pertanyaan lanjutan 5: Bolehkah sebuah Link berisi tenant.id?
Hanya setelah tinjauan akses, kardinalitas, dan privasi. Ekspor lintas-tenant biasanya melakukan hashing atau menghapusnya, dan tidak boleh dijadikan label metrik bervolume tinggi.