Pertanyaan dan skenario penggunaan
Sebuah permintaan HTTP memublikasikan pesan untuk pemrosesan asinkron. Bagaimana cara Anda mempropagasi Trace Context secara aman di seluruh retry, batch, dan tenant? Pertanyaan ini cocok untuk wawancara backend, observabilitas, dan sistem perpesanan. Tujuannya adalah korelasi kausal di seluruh batas eksekusi tanpa memperlakukan konteks permintaan sebagai otorisasi permanen atau data bisnis.
Hal yang dinilai oleh pewawancara
- Apakah Anda memahami batasan
traceparent,tracestateopsional, dan propagator. - Apakah span produser, pemrosesan pesan, dan span percobaan ulang (retry) memiliki hubungan parent yang jelas.
- Apakah Anda menangani pesan batch, konsumsi tertunda, dead letter, sampling, dan kedaluwarsa.
- Apakah Anda mencegah penyebaran baggage sensitif, data lintas-tenant, dan sinyal kepercayaan palsu.
Pertanyaan untuk diklarifikasi sebelum menjawab
Konfirmasikan mekanisme transport, ketahanan pesan (durability), perilaku batching dan retry, serta apakah konsumen melintasi batas layanan atau domain kepercayaan. Perjelas apakah hubungan yang diinginkan ditujukan untuk satu operasi bisnis, satu pesan, atau satu batch. Tanyakan tentang sampling, retensi, isolasi tenant, dan apakah produser eksternal diizinkan menginjeksikan konteks. Terakhir, tentukan penanganan dead-letter dan apakah pemutaran ulang (replay) manual menghasilkan cabang trace baru.
Kerangka jawaban 30 detik
“Layanan entri mengekstrak dan memvalidasi header propagasi, lalu menginjeksikan trace context minimal saat memublikasikan pesan. Konsumen mengekstraknya, membuat span konsumen independen, dan merepresentasikan retry, batch, serta dead letter secara eksplisit. Di seluruh domain kepercayaan, saya hanya menerima field yang terkontrol dan membuang baggage sensitif; kebijakan platform mengatur sampling dan kedaluwarsa, sementara replay menggunakan trace ID baru yang ditautkan ke aslinya.”
Jawaban mendalam langkah demi langkah
- Tentukan batasan: Modelkan ingress HTTP, publikasi pesan, transport, dan konsumsi sebagai unit eksekusi terpisah dengan pemilik injeksi dan ekstraksi yang eksplisit.
- Pilih pembawa (carrier): Tempatkan format propagasi standar dalam header pesan atau metadata terkontrol; jangan pernah menyalin seluruh permintaan, token identitas, atau baggage arbitrer ke dalam pesan yang persisten.
- Modelkan span: Penerbit membuat span produser dan konsumen membuat span konsumen; untuk batch, rekam tautan pesan alih-alih menganggap batch sebagai satu permintaan tunggal.
- Tangani retry dan dead letter: Berikan setiap percobaan span dan atribut percobaannya sendiri sembari mempertahankan tautan peristiwa asli; penanganan dead-letter dan replay akan membuat cabang baru.
- Kelola keamanan: Batasi injeksi lintas-domain, bersihkan field yang dikontrol pengguna, isolasi label tenant, dan batasi sampling, retensi, serta ukuran konteks.
Contoh jawaban berkualitas tinggi
Saya akan memisahkan konteks standar, korelasi bisnis, dan batasan keamanan. Titik masuk HTTP hanya mengekstrak header propagasi yang terbentuk dengan benar, memvalidasi versi dan panjangnya, lalu membuat span server. Saat memublikasikan, span produser menginjeksikan trace context minimal ke dalam metadata pesan, sementara ID peristiwa bisnis yang tidak dapat diubah (immutable) disimpan secara terpisah karena keduanya memiliki tujuan berbeda. Konsumen mengekstrak metadata dan membuat span konsumen; setiap operasi downstream mendapatkan span turunan (child) masing-masing. Sebuah batch tidak dipaksakan berada di bawah pesan pertama sebagai satu-satunya parent: saya mencatat span batch dan tautan pesan yang terikat. Setiap retry menambahkan atribut percobaan dan backoff sambil mempertahankan ID peristiwa. Setelah pesan masuk ke antrean dead-letter, replay manual akan membuat trace baru yang ditautkan ke trace asli sehingga eksekusi baru tidak menyamar sebagai histori lama. Baggage dari tenant lain atau produser eksternal akan dibuang secara default; hanya field beresiko rendah yang disetujui platform yang boleh melintasi batasan. Saya akan memvalidasi ukuran konteks, kegagalan ekstraksi, korelasi pesan-ke-konsumen, visibilitas retry, dan kebocoran lintas-tenant menggunakan pengujian serta metrik produksi.
Kesalahan umum
- Memperlakukan trace ID sebagai kredensial autentikasi atau kunci idempoten bisnis.
- Menyimpan header HTTP lengkap, input pengguna, atau token dalam pesan yang persisten.
- Menggabungkan konsumsi batch dan semua retry di bawah satu span tunggal, yang mendistorsi durasi waktu.
- Menggunakan kembali trace lama selama replay dead-letter, sehingga menyembunyikan percobaan yang baru.
- Membahas panggilan SDK tanpa mempertimbangkan domain kepercayaan, sampling, retensi, dan tata kelola ukuran data.
Pertanyaan lanjutan dan jawabannya
Sebuah pesan dicoba ulang sepuluh kali. Berapa banyak span yang seharusnya ada?
Buat span yang dapat dibedakan untuk setiap percobaan pemrosesan aktual dan tautkan dengan nomor percobaan, ID peristiwa, serta operasi produser asli. Hal ini menunjukkan latensi per percobaan tanpa melaporkan sepuluh eksekusi sebagai satu kesatuan.
Bagaimana cara memilih parent untuk sebuah batch?
Buat span konsumen untuk batch tersebut, lalu gunakan tautan terikat atau span anak untuk pesan-pesan yang memerlukan analisis. Jangan memilih pesan pertama secara sembarangan sebagai parent batch; pertahankan statistik tingkat batch dan ID korelasi saat sampling dibatasi.
Bolehkah pelanggan eksternal menginjeksikan tracestate?
Terima field yang sesuai protokol hanya sebagai input yang tidak tepercaya. Di seluruh batas kepercayaan, batasi panjang, kunci, dan penerusan, hapus field sensitif atau ber-kardinalitas tinggi, dan jangan pernah menggunakannya untuk otorisasi.
Bagaimana replay dead-letter manual tetap dapat dilacak?
Buat trace dan span eksekusi baru untuk replay, dengan mencatat ID pesan asli, operator, alasan, dan batch replay. Tautkan trace lama dan baru melalui relasi yang terkontrol sembari mempertahankan kegagalan asli yang tidak dapat diubah.