Perintah dan konteks
Sebuah layanan sedang mengadopsi OpenTelemetry dan tim ingin menyertakan userid, requestid, dan URL lengkap sebagai atribut metrik. Rancang anggaran kardinalitas, jelaskan apa yang dipertahankan, apa yang terjadi pada batas limit, dan bagaimana Anda membuktikan bahwa peringatan (alert) tetap berguna.
Metrik OpenTelemetry membuat deret waktu (time series) dari kombinasi atribut. Batas kardinalitas SDK adalah batas mutlak (hard limit) pada titik-titik metrik yang dilacak untuk suatu metrik selama siklus pengumpulan. Kolom dengan kardinalitas tinggi melipatgandakan biaya memori, ekspor, penyimpanan, dan kueri, sehingga anggaran harus melindungi biaya sekaligus nilai diagnostik.
Apa yang sedang diuji oleh pewawancara
Pewawancara menguji apakah Anda memisahkan dimensi metrik, log, dan trace, memahami kombinasi daripada sekadar hitungan kolom tunggal, merancang batas mutlak dan degradasi, serta mengoperasionalkan service graph, peringatan, sampling, dan batasan privasi.
Pertanyaan klarifikasi
Konfirmasikan tujuan metrik, jendela kueri, latensi peringatan, jumlah tenant, jumlah endpoint, interval pengumpulan, retensi backend, dan anggaran. Tanyakan apakah kolom korelasi trace atau log sudah ada, kolom identitas mana yang sensitif terhadap privasi, dan apakah batasan tersebut harus mengutamakan nilai baru, nilai lama, atau akurasi agregat.
Jawaban 30 detik
“Saya akan menentukan dimensi yang diizinkan berdasarkan tujuan metrik daripada memasukkan semua konteks ke dalam metrik. Pertahankan kolom stabil ber-kardinalitas rendah yang mendukung pengelompokan peringatan, seperti service, region, template rute, dan kelas status; masukkan userid, requestid, dan URL mentah ke dalam trace atau log. Tetapkan batas kardinalitas, peringatan biaya, dan sinyal saturasi per metrik, dengan kebijakan agregasi atau drop yang eksplisit. Terakhir, putar ulang traffic historis untuk mengukur recall peringatan, false positive, biaya kueri, dan privasi.”
Jawaban mendalam
Langkah 1: Tentukan pertanyaan metrik
Tuliskan pertanyaannya: Apakah tingkat kesalahan meningkat, rute mana yang terpengaruh, region mana yang mengalami penurunan performa, atau apa yang terjadi pada satu permintaan pengguna? Kasus-kasus pertama cocok untuk metrik; kasus terakhir termasuk dalam trace atau log.
Langkah 2: Perkirakan kardinalitas kombinasi
Kardinalitas adalah himpunan unik dari kombinasi atribut, bukan jumlah nilai di setiap kolom. Perkirakan hasil kali dari service, region, template rute, status, metode, dan tingkatan tenant, lalu koreksi dengan distribusi riil, long tail, dan lonjakan (burst).
Langkah 3: Lapisi kolom-kolom
Pertahankan kolom yang stabil dan dapat diagregasikan; masukkan pengguna, permintaan, dan URL lengkap ke dalam trace atau log. Untuk pengidentifikasi tenant ber-kardinalitas tinggi, gunakan bucketing, hashing, atau sampling hanya jika kontrol akses dan kebutuhan investigasi tetap terpenuhi. Jangan pernah membuat deret tanpa batas dari parameter jalur (path) mentah.
Langkah 4: Konfigurasikan anggaran SDK dan backend
Tetapkan anggaran di SDK, Collector, backend deret waktu, dan lapisan kueri, alih-alih memotongnya hanya di bagian akhir. Batas kardinalitas metrik OpenTelemetry adalah batas mutlak, dan kumpulan atribut yang dipertahankan harus dapat diobservasi dalam implementasi dan peringatan.
Langkah 5: Tentukan perilaku saat batas tercapai
Tentukan kombinasi mana yang tetap bertahan, apakah overflow bucket digunakan, apakah kumpulan baru dibuang, dan bagaimana keputusan tersebut dihitung. Kebijakan harus stabil dan dapat dijelaskan, disertai sinyal saturasi; kehilangan data secara diam-diam (silent loss) tidak dapat diterima.
Langkah 6: Tempatkan korelasi pada sinyal yang tepat
Gunakan traceid untuk permintaan, log untuk URL mentah atau userid, dan exemplar atau tautan untuk melompat dari metrik ke sampel. Metrik memberikan tren dan peringatan; metrik tidak menggantikan diagnosis per permintaan.
Langkah 7: Anggarkan service graph dan biaya
Service graph dan auto-instrumentation dapat membuat banyak famili metrik. Tetapkan anggaran terpisah untuk edge, klien, server, dan status kesalahan, serta kendalikan frekuensi ekspor, retensi, dan atribut ber-kardinalitas tinggi. Distribusikan laporan biaya ke layanan dan metrik alih-alih hanya melihat total keseluruhannya.
Langkah 8: Validasi kualitas peringatan dan privasi
Putar ulang traffic dan lakukan injeksi kegagalan untuk membandingkan recall, false positive, latensi, dan biaya kueri dengan dan tanpa anggaran. Periksa redaksi data, kontrol akses, permintaan penghapusan, dan isolasi tenant, serta pastikan saturasi, perubahan konfigurasi, dan kehilangan data dapat dilacak.
Contoh jawaban
Saya akan memisahkan peringatan tren dari investigasi permintaan tunggal. Service, region, template rute, metode, dan kelas status biasanya merupakan atribut metrik yang stabil dan ber-kardinalitas rendah; userid, requestid, dan URL berparameter termasuk dalam trace, log, dan exemplar. Saya akan memperkirakan hasil kali kombinasi atribut dan mengoreksinya dengan traffic long-tail, kemudian mengonfigurasi anggaran kardinalitas dan biaya di SDK, Collector, dan backend. Pada batas limit, gunakan kebijakan overflow atau drop yang eksplisit dan catat saturasi daripada gagal secara diam-diam. Buat anggaran untuk edge service-graph, klien, dan status kesalahan secara independen, dengan mengontrol pengumpulan dan retensi. Sebelum peluncuran, putar ulang traffic dan lakukan injeksi kasus kardinalitas tinggi serta kegagalan, bandingkan recall peringatan, false positive, biaya kueri, privasi, dan isolasi tenant.
Kesalahan umum
Menghitung setiap kolom secara independen
Deret waktu berasal dari kombinasi. Beberapa kolom ber-kardinalitas sedang dapat berlipat ganda menjadi ledakan kardinalitas, jadi perkirakan kombinasi, long tail, dan lonjakannya.
Memasukkan user_id ke dalam setiap metrik
Investigasi tingkat pengguna termasuk dalam trace dan log. Dimensi identitas dalam metrik menambah biaya, risiko privasi, dan derau (noise) kueri.
Membuang data secara diam-diam pada batas limit
Kehilangan data secara diam-diam membuat peringatan terlihat normal padahal tidak. Catat saturasi, aturan retensi, dan versi konfigurasi, lalu uji diagnosis yang terdegradasi.
Pertanyaan lanjutan dan jawaban
Bagaimana template rute harus dibedakan dari URL lengkap?
Metrik menggunakan template rute yang dinormalisasi sehingga parameter jalur tidak membuat deret baru. URL lengkap masuk ke log atau trace yang terkontrol dengan redaksi privasi.
Haruskah batas mempertahankan kumpulan atribut lama atau baru?
Hal ini tergantung pada peringatan dan agregator, namun aturannya harus tetap, dapat dijelaskan, dan dapat diobservasi. Hitung overflow agar instance tidak berperilaku secara inkonsisten.
Bagaimana Anda menghubungkan metrik, trace, dan log?
Gunakan traceid, spanid, atau exemplar untuk menautkan sampel. Pertahankan dimensi stabil dalam metrik, konteks permintaan dalam log dan trace, serta tegakkan batasan akses saat melakukan navigasi.
Mengapa service graph membutuhkan anggarannya sendiri?
Edge, klien, dan dimensi kesalahan yang dibuat secara otomatis melipatgandakan deret waktu. Bagi anggaran berdasarkan jenis edge, frekuensi pengumpulan, dan retensi sehingga grafik tidak mengesampingkan metrik bisnis.
Bagaimana Anda membuktikan bahwa anggaran tidak menyembunyikan kegagalan?
Putar ulang traffic nyata dan lakukan injeksi kardinalitas tinggi, lonjakan kesalahan, dan long tail tenant. Bandingkan recall, false positive, latensi, dan hasil kueri sebelum dan sesudah anggaran sembari memantau peristiwa saturasi.
Kapan sebaiknya Anda menambahkan log daripada metrik?
Ketika pertanyaannya membutuhkan satu permintaan, input mentah, atau konteks pengguna, gunakan log atau trace yang terkontrol. Metrik harus membawa tren yang dapat diagregasikan dan dimensi peringatan.