Petunjuk dan cakupan
Propagasi konteks dapat membuat permintaan dapat dipahami melintasi batas layanan, tetapi setiap layanan downstream dapat menerima dan mencatat nilai yang dipropagasikan ke dalam log. OpenTelemetry mendokumentasikan Baggage sebagai konteks nama/nilai yang berdampingan dengan konteks trace dan memperingatkan tentang implikasi keamanannya. Keterampilan intinya adalah perancangan batas terdistribusi (distributed-boundary design), sehingga ini adalah pertanyaan system-design.
Hal yang dinilai oleh pewawancara
Jawaban yang kuat memisahkan konteks trace dari metadata aplikasi, menentukan allowlist dan kepemilikan untuk setiap bidang (field), serta mencegah nilai sensitif melintasi batas yang tidak tepercaya. Mereka mencakup ukuran header, canonical encoding, sampling, percobaan ulang (retries), pesan asinkron, dan apa yang terjadi jika konteks salah format atau hilang. Mereka juga menyertakan metrik yang membuktikan bahwa propagasi berguna tanpa mengubahnya menjadi saluran data yang tidak terkendali.
Pertanyaan klarifikasi di awal
- Protokol apa yang membawa konteks: HTTP, gRPC, antrean (queues), atau scheduled jobs?
- Bidang mana yang bersifat diagnostik, mana yang memengaruhi perilaku, dan siapa yang memiliki masing-masing bidang?
- Batas kepercayaan (trust boundaries) apa yang ada di antara tenant, wilayah (regions), dan layanan pihak ketiga?
- Apakah nilai diizinkan dalam log, label metrik, atau hanya traces?
- Berapa anggaran maksimum untuk ukuran header, latensi, dan ketersediaan?
- Apakah konteks yang salah format harus ditolak (rejected), dilucuti (stripped), atau diganti dengan root baru?
Kerangka jawaban 30 detik
"Saya akan menentukan envelope kecil berversi dengan konteks trace yang terpisah dari bidang bisnis yang disetujui. Di setiap batas, pustaka kebijakan memvalidasi nama, ukuran, pengodean, cakupan tenant, dan kepercayaan tujuan; pustaka ini melucuti atau menolak nilai yang tidak diizinkan dan tidak pernah meneruskan rahasia (secrets). Propagasi harus berfungsi untuk tepi sinkron dan asinkron, dengan header yang dibatasi dan perilaku yang jelas saat konteks hilang. Saya akan mengukur kegagalan ekstraksi, pemotongan (truncation), cakupan propagasi, pelanggaran lintas-tenant, dan rasio penggabungan trace (trace join rate)."
Jawaban langkah demi langkah
Langkah 1: Tentukan kontrak konteks
Buat registri bidang dengan pemilik, tipe, panjang maksimum, sensitivitas, retensi, dan tujuan yang diizinkan. Simpan pengidentifikasi trace dalam protokol pelacakan dan masukkan hanya metadata bisnis yang disetujui ke dalam carrier terpisah yang mirip dengan baggage. Beri versi pada envelope sehingga konsumen dapat menolak bidang penting yang tidak dikenal.
Langkah 2: Terapkan kebijakan batas
Gunakan middleware bersama atau kebijakan sidecar yang mengurai carrier, memvalidasi pengodean dan ukuran, memeriksa tenant dan zona kepercayaan, serta menghasilkan carrier yang telah dibersihkan (sanitized). Jangan pernah menyalin sembarang header masuk ke dalam permintaan keluar. Perlakukan panggilan pihak ketiga dan lintas-tenant sebagai trust roots baru kecuali ada kebijakan eksplisit yang mengizinkan penerusan.
Langkah 3: Tangani transportasi dan percobaan ulang
Tentukan carrier yang setara untuk HTTP, metadata gRPC, dan atribut pesan. Pertahankan hanya bidang yang diperlukan untuk menghubungkan pekerjaan asinkron; jangan membuat serialisasi rahasia ke dalam antrean. Pada percobaan ulang, pertahankan relasi trace asli sambil mencegah keputusan bisnis yang duplikat atau usang dipercaya tanpa validasi ulang.
Langkah 4: Rancang perilaku saat terjadi kegagalan
Konteks yang salah format atau berukuran terlalu besar harus dilucuti atau ditolak sesuai dengan risiko endpoint, sementara permintaan itu sendiri tetap dapat diobservasi dengan root trace lokal baru jika aman. Tampilkan counter berkode alasan (reason-coded counters), bukan nilai mentah. Buat versi kebijakan dan hasil penegakan dapat dilihat oleh operator.
Langkah 5: Operasikan dan buktikan nilai
Lacak rasio penggabungan trace, kegagalan ekstraksi dan injeksi, byte yang ditambahkan, pemotongan, penolakan kebijakan, pelanggaran lintas-batas, dan kesalahan serialisasi antrean. Lakukan sampling dengan aman dan hindari label metrik berkardinalitas tinggi yang tidak terbatas. Tambahkan pengujian kontrak untuk setiap protokol yang didukung dan peluncuran kebijakan canary sebelum menerapkan penolakan.
Contoh jawaban model
"Saya akan memperlakukan konteks yang dipropagasikan sebagai saluran data yang tidak tepercaya. Registri berversi menentukan bidang diagnostik dan bisnis mana yang boleh berpindah, sensitivitas, dan ukurannya. Middleware memvalidasi dan membersihkan setiap hop, dengan aturan yang lebih ketat untuk panggilan pihak ketiga dan lintas-tenant; rahasia tidak pernah masuk ke dalam carrier atau antrean. Konteks trace tetap terpisah dari baggage bisnis. Saya akan mendukung atribut HTTP, gRPC, dan asinkron, menentukan pelucutan versus penolakan, serta mengukur join rate, kegagalan kebijakan, byte, dan pelanggaran. Peluncuran canary dan metrik berkode alasan memungkinkan kita memperketat kebijakan tanpa kehilangan observabilitas."
Kesalahan umum
- Meneruskan setiap header masuk → data yang tidak tepercaya melintasi batas → gunakan allowlist dan sanitizer.
- Memasukkan token atau PII ke dalam baggage → log dan layanan downstream dapat mengeksposnya → jangan masukkan data sensitif.
- Menggunakan baggage sebagai label metrik → kardinalitas dan biaya melonjak drastis → catat kode alasan dan dimensi yang dibatasi.
- Mengabaikan antrean dan percobaan ulang → pekerjaan asinkron kehilangan atau memercayai konteks yang usang → tentukan kontrak khusus transportasi dan validasi ulang.
- Menolak setiap permintaan yang salah format → observabilitas dan ketersediaan terganggu → pilih pelucutan atau penolakan berdasarkan risiko endpoint.
- Tidak ada anggaran ukuran → header menyebabkan kegagalan proxy → batasi setiap bidang dan total carrier.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Haruskah ID tenant dipropagasikan?
Hanya jika tujuan diotorisasi untuk tenant tersebut dan nilainya divalidasi terhadap identitas yang diautentikasi. Nilai tersebut tidak boleh menjadi otoritas dengan sendirinya.
Pertanyaan lanjutan 2: Apa perbedaan antara konteks trace dan baggage?
Konteks trace menghubungkan spans dan status propagasi. Baggage membawa data nama/nilai yang ditentukan aplikasi sehingga memerlukan kebijakan sensitivitas, kepemilikan, dan tujuan yang lebih ketat.
Pertanyaan lanjutan 3: Bagaimana cara mencegah pertumbuhan header?
Tetapkan anggaran per-bidang dan total, tolak atau potong dengan metrik berkode alasan, dan utamakan referensi terbatas ke state sisi server saat konteks yang lebih besar tidak dapat dihindari.
Pertanyaan lanjutan 4: Apa yang terjadi pada batas yang tidak tepercaya?
Lucuti bidang yang tidak disetujui, buat atau lanjutkan hanya informasi trace yang diizinkan oleh kebijakan, dan catat keputusan kebijakan ke dalam log tanpa mencatat nilai sensitif.