Wawancara data engineering: Bagaimana Anda menggunakan exemplar metrik untuk menghubungkan metrik ke trace?

Perintah dan konteks

Histogram latensi untuk API multi-tenant menunjukkan regresi p99 selama lonjakan trafik. Menambahkan user_id, URL lengkap, atau parameter request sebagai label metrik akan menciptakan deret waktu (time series) dan biaya yang tak terbatas. Hanya melihat bucket agregat tidak dapat mengidentifikasi satu request yang lambat. Rancang exemplar metrik yang menyematkan sejumlah kecil referensi trace ke sampel metrik sehingga penyelidik dapat berpindah dari grafik ke trace, lalu ke log dan dependensi.

Pertanyaan ini menguji apakah Anda memisahkan semantik agregasi metrik dari referensi exemplar eksternal. OpenTelemetry mendefinisikan exemplar sebagai nilai tercatat yang terkait dengan peristiwa metrik; exemplar dapat membawa trace_id, span_id, waktu observasi, dan atribut yang difilter. OpenMetrics juga memerlukan nilai, set label, dan timestamp. Metrik utama harus tetap ber-kardinalitas rendah; exemplar bukanlah sistem label tersembunyi.

Hal yang dievaluasi pewawancara

Anda memahami bahwa exemplar tidak mengubah bucket, count, atau sum histogram; exemplar merujuk pada observasi di luar agregat.
Anda dapat memilih sampling berbasis trace atau probabilistik dan menjelaskan kompromi (trade-off) antara laju, cakupan latensi ekor (tail-latency coverage), dan biaya.
Anda menggunakan referensi stabil seperti trace_id dan span_id, tanpa memasukkan request lengkap, token, atau data pribadi ke dalam metrik.
Anda menangani timestamp, penataan ulang urutan (reordering), backend drop, retensi, dan otorisasi lintas-tenant alih-alih hanya membuat tautan.
Anda menggunakan metrik ber-kardinalitas rendah untuk menemukan rentang waktu, lalu menggunakan exemplar untuk memvalidasi trace yang representatif dan menelusuri log, dependensi, serta versi build.

Pertanyaan untuk diklarifikasi terlebih dahulu

Backend metrik, backend trace, dan alat visualisasi apa yang digunakan, dan apakah semuanya mendukung kueri exemplar serta deep link?
Instrumen mana yang masuk dalam cakupan: Histogram, Counter, atau Gauge? Apakah p99 diukur pada layanan atau gateway?
Apakah sampling harus menargetkan setiap error, tail latency, atau anggaran per tenant dan versi? Apakah ada satu kebijakan lintas-wilayah?
Aturan retensi, kontrol akses, redaksi (redaction), dan isolasi tenant apa yang membatasi referensi?
Berapa anggaran memori, jaringan, dan penyimpanan yang berlaku, dan apakah metrik utama harus tetap tersedia saat exemplar di-drop?

Jawaban 30 detik

"Saya mempertahankan histogram latensi ber-kardinalitas rendah dan menyematkan trace_id, span_id, nilai observasi, dan timestamp hanya untuk set kecil yang disampel. Sampling memprioritaskan error dan tail latency; pengidentifikasi pengguna tidak dimasukkan ke dalam label metrik. Backend metrik menyimpan referensi berumur pendek, dan pemeriksaan izin mendahului deep link ke trace. Saya memverifikasi bahwa statistik bucket tidak berubah, rentang waktu mengembalikan exemplar, dan drop tidak memengaruhi metrik utama. Saya menerapkan gerbang kendali (gate) pada hit rate, keberhasilan tautan, overhead memori, dan pemindaian bidang sensitif."

Solusi langkah demi langkah

Langkah 1: Tetapkan batas metrik/exemplar

Batasi label histogram pada dimensi terbatas seperti service, route_template, region, dan status_class. Observasi tetap berkontribusi pada bucket_counts, count, dan sum; exemplar menyimpan satu referensi yang dapat dilacak dan tidak boleh membuat time series baru per trace.

Langkah 2: Lakukan sampling untuk cakupan tail

Tentukan sampling trace dalam konteks request, lalu sematkan observasi ke sampel Histogram yang relevan saat disampel dan cocok dengan error, ambang batas latensi, atau anggaran per dimensi. Gunakan kapasitas tetap per layanan dan metrik, seperti reservoir atau ring buffer. Berikan versi pada perubahan sampling agar hit count tidak disalahartikan sebagai volume trafik.

Langkah 3: Encode referensi dan waktu

Exemplar berisi nilai numerik, set label, dan waktu observasi; referensi trace harus menggunakan trace_id dan span_id. Timestamp harus mendekati waktu observasi dan selaras dengan jendela sampel metrik. Penerima dapat memotong label atau membuang exemplar, sehingga jalur kueri harus mendukung kondisi 'metrik ada, exemplar tidak ada'.

text

latency_seconds_bucket{route="/checkout",le="1"} 982
# {trace_id="4f8...",span_id="91a...",build="2026.07.31"} 1.42 1753938000000

Langkah 4: Batasi privasi, kardinalitas, dan biaya

Jangan pernah memasukkan URL mentah, body, alamat email, token otorisasi, atau ID pengguna ke dalam exemplar. Atribut opsional seperti build dan wilayah memerlukan allowlist dan batasan panjang. OpenTelemetry mencatat bahwa atribut yang dihapus dari stream metrik oleh View mungkin masih diekspor sebagai atribut terfilter exemplar, sehingga redaksi harus dikonfigurasi secara terpisah. Perkirakan sampel per detik, byte per catatan, memori ring-buffer, remote write, dan biaya kueri trace; kurangi sampling exemplar sebelum mencemari label metrik.

Langkah 5: Terapkan perpindahan lintas-backend

Dasbor meminta kueri exemplar untuk rentang waktu yang dipilih, lalu membuat tautan backend trace yang terkontrol dari trace_id. Layanan tautan memeriksa tenant, wilayah, dan otorisasi, serta mengembalikan status eksplisit untuk trace yang hilang, kedaluwarsa, atau lintas-lingkungan. Log dan span berbagi Trace Context, tetapi ketiga sinyal tersebut tidak memerlukan satu sistem penyimpanan yang sama.

Langkah 6: Uji degradasi dan gerbang rilis

Putar ulang (replay) trafik tetap dan bandingkan bucket, count, sum, dan p99 sebelum dan sesudah mengaktifkan exemplar untuk membuktikan bahwa agregasi tidak berubah. Injeksikan request yang lambat dan error untuk memeriksa hit rate, timestamp, lompatan trace, dan isolasi tenant. Tunda, potong, atau nonaktifkan backend exemplar dan pastikan kueri metrik tetap berfungsi. Gerbang rilis harus mencakup pemindaian bidang sensitif, batas atas memori, tingkat kegagalan remote-write, keberhasilan lompatan, dan keadilan sampling berdasarkan layanan dan versi.

Contoh jawaban yang kuat

"Pertama, saya membatasi label metrik pada template rute, kelas status, dan wilayah, membiarkan histogram bertanggung jawab atas agregasi p99. Request membawa Trace Context; saat trace yang disampel cocok dengan kebijakan error atau tail-latency, saya menyematkan trace_id, span_id, nilai, dan timestamp ke sampel Histogram. Atribut exemplar dimasukkan ke dalam allowlist, tidak memuat identitas pengguna atau body, dan diredaksi kembali sebelum ekspor View."

"Kueri Prometheus/OpenMetrics mengembalikan exemplar hanya untuk jendela yang dipilih. Pemeriksaan izin mendahului tautan trace; jika trace telah kedaluwarsa, metrik tetap terlihat dengan status referensi kedaluwarsa. Uji beban membandingkan bucket/count/sum/p99, dan simulasi mencakup backend drop, reordering, akses lintas-tenant, dan anggaran yang habis. Hit rate, waktu ke trace pertama, memori, biaya penulisan, dan pemindaian bidang sensitif menentukan anggaran sampling; label ber-kardinalitas tinggi tidak pernah masuk ke dalam metrik."

Kesalahan umum

Memasukkan trace_id ke dalam label metrik → ledakan time-series → simpan di dalam referensi exemplar.
Hanya menggunakan sampling probabilitas tetap → p99 atau error bisa tidak muncul dalam periode lama → tambahkan sampling tail, error, dan berbasis anggaran.
Mengabaikan timestamp exemplar → trace berada di luar jendela grafik → catat waktu observasi dan validasi jendelanya.
Mengasumsikan atribut terfilter itu aman → data sensitif mungkin masih diekspor bersama exemplar → gunakan allowlist, redaksi, dan pemeriksaan otorisasi terpisah.
Menganggap exemplar yang hilang sebagai kegagalan metrik → agregasi menjadi terikat dengan referensi → pertahankan ketersediaan metrik dan pantau hilangnya exemplar secara terpisah.
Menyimpan referensi tanpa batas → memori dan biaya membengkak tanpa kendali → gunakan kapasitas tetap, retensi, dan anggaran sampling.

Pertanyaan lanjutan dan jawaban

Apakah exemplar mengubah p99?

Tidak. Nilainya sudah disertakan dalam bucket, count, dan sum Histogram. Exemplar menambahkan konteks dan referensi; exemplar tidak boleh membuat deret metrik lain atau menghitung observasi dua kali.

Mengapa tidak memasukkan URL lengkap ke dalam atribut exemplar?

URL lengkap dapat memuat data pengguna, token, dan kardinalitas tak terbatas. Gunakan template rute dan versi yang ada di allowlist; periksa parameter dalam trace atau log yang telah terotorisasi dan diredaksi.

Apa yang terjadi jika semua exemplar di-drop?

Kueri metrik dan pemberitahuan (alert) terus menggunakan deret agregat. Penyelidik kehilangan jalan pintas dari metrik ke trace, jadi pantau tingkat penerimaan exemplar dan keberhasilan lompatan; jalur referensi tidak boleh memblokir penyerapan (ingestion) metrik.

Bagaimana Anda membuktikan bahwa sampling tidak bias terhadap satu tenant?

Bandingkan jumlah request, sampel, dan hit berdasarkan tenant, wilayah, versi, dan kelas hasil. Tetapkan jaminan minimum dan anggaran maksimum, lalu bandingkan hit rate error dan tail-latency. Perbaiki bias dengan stratified sampling daripada menaikkan laju global.