Topik wawancara representatif

Wawancara data: Bagaimana Anda merancang pipeline exponential-histogram OpenTelemetry dengan kontrol biaya?

DataSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Anda perlu mengirim metrik latensi high-dynamic-range dari OpenTelemetry ke Prometheus. Bagaimana Anda memilih histogram eksponensial, menggabungkannya dengan benar, dan mencegah lonjakan biaya penyimpanan serta kueri?

Perintah

Rancang pipeline metrik latensi untuk layanan multi-wilayah: SDK memancarkan data ExponentialHistogram OpenTelemetry, sebuah Collector menggabungkannya, dan backend menulis histogram native Prometheus. Jelaskan semantik, jalur downgrade, dan kontrol biaya.

Skenario dan batasan

Latensi berkisar dari mikrodetik hingga hitungan menit dan layanan memiliki label ber-kardinalitas tinggi. Beberapa backend hanya mendukung bucket klasik, batch dapat hilang, dan kueri memerlukan p50, p95, serta agregasi lintas wilayah. Metrik tidak boleh mengekspos data penyewa atau membuat deret waktu tanpa batas.

Apa yang diuji

Ujian ini mencakup batas eksponensial, skala, bucket positif dan negatif, jumlah nol, count/sum, temporalitas, dan kemampuan penggabungan lintas proses. OpenTelemetry mengompresi batas eksponensial untuk rentang dinamis tinggi dengan kesalahan relatif kecil; histogram native Prometheus dapat memetakan model tersebut, tetapi konversi dan kueri harus mempertahankan maknanya.

Pendekatan referensi

Catat hanya dimensi bisnis dan observasi yang disetujui di dalam SDK. Gabungkan skema yang sama di Collector berdasarkan layanan, wilayah, dan jendela waktu tetap. Konversikan secara eksplisit ke bucket klasik terbatas untuk backend yang tidak didukung dan catat hilangnya presisi. Batasi skala, jumlah bucket, rangkaian label, dan anggaran per-penyewa; lakukan downsampling atau tolak label baru pada batas yang ditentukan daripada memotongnya secara diam-diam.

Detail penting

Periksa temporalitas, temporalitas agregasi, skema, bucket positif dan negatif, serta rentang waktu sebelum menggabungkan; skema yang berbeda tidak dapat ditambahkan secara langsung. Kueri p95 sebagai perkiraan dan tampilkan jumlah sampel, kesalahan, serta penanda downgrade. Gunakan nomor urut batch dan percobaan ulang untuk menghindari penghitungan batch dua kali.

Jebakan umum

Menyebut bucket eksponensial sebagai kuantil pasti; menjumlahkan temporalitas yang berbeda; mengizinkan label tanpa batas; mengonversi semuanya ke skala terbaik; mengabaikan angka negatif, bucket nol, dan duplikasi akibat percobaan ulang; serta mengukur penyimpanan tanpa memperhitungkan amplifikasi kueri.

Rubrik evaluasi

Jawaban yang kuat mendefinisikan batasan SDK, Collector, remote-write, kueri, dan kontrol anggaran; menyatakan invarian penggabungan dan kebijakan downgrade; serta menjelaskan kesalahan p95. Mengatakan “gunakan histogram_quantile” tanpa model data atau analisis biaya tidaklah cukup.

Pertanyaan lanjutan

Mengapa skema eksponensial yang berbeda tidak dapat digabungkan secara langsung?

Indeks bucket mereka memetakan ke batas yang berbeda, sehingga penambahan akan menempatkan observasi pada rentang yang salah. Petakan ulang ke skema yang kompatibel sesuai dengan spesifikasi dan catat perubahan presisinya.

Bagaimana Anda menangani temporalitas kumulatif dan delta secara bersamaan?

Konversikan secara eksplisit di Collector sambil mempertahankan nilai awal dan nilai sebelumnya dari setiap aliran. Jika kontinuitas hilang, buang atau tandai jendela yang tidak lengkap; jangan pernah menambahkan nilai kumulatif sebagai delta.

Kapan Anda harus beralih kembali ke histogram klasik?

Gunakan bucket klasik terbatas ketika backend tidak memiliki dukungan native, kepatuhan memerlukan rentang tetap, atau ekosistem kueri tidak dapat menginterpretasikan bucket eksponensial. Publikasikan kompromi antara kesalahan dan biaya alih-alih membiarkan konsumen menebak-nebak.

Sumber publik

Pertanyaan terkait