Petunjuk dan konteks
Tim menggunakan pustaka logging dan agen yang berbeda, dengan tingkatan mulai dari TRACE dan DEBUG hingga CRITICAL. Jelaskan cara memetakannya ke SeverityNumber dan SeverityText OpenTelemetry, mempertahankan informasi sumber, serta menangani exception, sampling, kueri, dan migrasi versi.
Hal yang diuji oleh pewawancara
- Membedakan SeverityNumber yang terstandardisasi, SeverityText sumber, dan body log.
- Memahami bahwa rentang numerik mengekspresikan tingkat keparahan dan tingkatan bernama sama tidak harus memiliki arti yang identik di seluruh sistem.
- Menggabungkan event exception, atribut resource, korelasi trace/span, dan transformasi collector.
- Memperhitungkan tingkatan yang tidak diketahui, bias sampling, kompatibilitas kueri, ambang batas peringatan (alert thresholds), dan validasi replay.
Pertanyaan klarifikasi yang perlu diajukan
- Apa arti tingkatan pada setiap sumber, rentang numerik apa yang digunakannya, dan apakah sumber tersebut mendefinisikan tingkatan kustom?
- Apakah string tingkatan asli, pustaka logging, dan versinya harus dipertahankan? Bidang mana yang digunakan oleh kueri hilir (downstream)?
- Apakah exception merupakan event terpisah atau teks body biasa, dan apakah itu harus ditautkan ke trace, span, atau ID permintaan?
- Akankah pemetaan mengubah peringatan, sampling, biaya penyimpanan, atau kepatuhan retensi? Bagaimana log historis akan di-replay?
Jawaban 30 detik
Saya akan membangun kamus semantik untuk setiap sumber, lalu memetakan artinya ke rentang SeverityNumber OpenTelemetry sambil mempertahankan SeverityText asli dan metadata sumber. Exception menggunakan semantik exception standar dan korelasi trace/span; stack trace tidak boleh dijejalkan ke dalam bidang level. Collector mentransformasi dan memvalidasi rekaman, sementara tingkatan yang tidak diketahui mengikuti jalur fallback yang dapat diobservasi. Sebelum peluncuran, saya akan me-replay sampel representatif dan kegagalan untuk memeriksa ambang batas peringatan, sampling, kueri, dan biaya daripada secara diam-diam mendefinisikan ulang semua riwayat.
Pembahasan mendalam langkah demi langkah
1. Tentukan bidang standar
OpenTelemetry Logs Data Model memisahkan SeverityNumber dan SeverityText. Number mendukung perbandingan di dalam model; Text mempertahankan nama asli atau nama tampilan produsen. Body, atribut, resource, dan timestamp membawa semantik lainnya. Tabel pemetaan harus mencatat sumber, tingkat asli, rentang target, dan alasannya alih-alih menyembunyikan semuanya di dalam kode konversi.
2. Petakan sumber ke rentang semantik
WARN, ERROR, atau FATAL dapat memicu tindakan operasional yang berbeda di berbagai framework. Petakan berdasarkan arti ke suatu rentang, pertahankan tingkat yang belum dikonfirmasi sebagai belum ditentukan (undefined) atau berkeyakinan rendah (low confidence), dan letakkan nilai asli di SeverityText atau atribut yang terkontrol. Jangan membandingkan angka mentah antar sistem sampai dokumentasi dan sampel dari masing-masing sumber diverifikasi.
3. Tangani exception dan korelasi
Semantik exception OpenTelemetry merekomendasikan bidang untuk tipe exception, pesan, dan stack trace, dengan tingkat keparahan yang dipilih berdasarkan apakah exception tersebut menyebabkan kegagalan aplikasi. Log harus membawa trace ID, span ID, layanan, dan versi deployment sehingga kueri dapat membedakan rekaman dari satu permintaan. Stack trace adalah data diagnostik dan memerlukan kontrol data sensitif serta retensi yang sama seperti log lainnya.
4. Validasi penyerapan (ingestion), peringatan, dan migrasi
Lakukan pemetaan, validasi bidang, dan konversi kompatibilitas di Collector atau agen edge, catat nilai yang tidak valid dan alasan pembuangan (drop reasons). Replay sampel historis dan kegagalan sintetis untuk memverifikasi ambang batas peringatan, sampling, hasil kueri, dan biaya penyimpanan. Selama peningkatan versi, pertahankan versi pemetaan dan bidang sumber sehingga konsumen dapat menafsirkan riwayat berdasarkan versi alih-alih mengubah arti peringatan secara diam-diam.
Jawaban model
Saya akan membuat pemetaan semantik terdokumentasi untuk Java, Python, Nginx, dan sumber lainnya, menargetkan SeverityNumber OpenTelemetry sambil mempertahankan nama asli di SeverityText dan atribut yang terkontrol. Angka hanya dibandingkan di dalam model yang sama; tingkat yang tidak diketahui atau kustom mengikuti jalur berkeyakinan rendah dengan peringatan. Exception menggunakan bidang exception OpenTelemetry dan terhubung ke trace/span serta versi layanan. Collector menangani transformasi, validasi, dan metrik. Sampel historis dan kegagalan di-replay untuk menguji peringatan, sampling, kueri, dan biaya. Versi pemetaan dan bidang sumber tetap tersedia untuk kebutuhan auditabilitas.
Kesalahan umum
- Memetakan ERROR, WARN, atau FATAL dari setiap sumber secara satu-ke-satu tanpa memeriksa semantiknya.
- Hanya mempertahankan SeverityNumber dan membuang tingkat asli serta versi sumber.
- Memasukkan data exception ke dalam body dan membuat stack trace sulit dikueri atau tidak aman untuk disimpan.
- Mengabaikan korelasi trace/span dan kehilangan konteks tingkat permintaan.
- Secara diam-diam membuang pemetaan yang gagal atau memaksanya menjadi INFO tanpa metrik atau peringatan.
- Menghitung ulang peringatan historis setelah perubahan pemetaan tanpa versi atau rekaman replay.
Pertanyaan lanjutan dan tanggapan
Angka apa yang harus digunakan untuk tingkat yang tidak diketahui?
Pertahankan teks asli dan tandai sebagai tidak diketahui atau berkeyakinan rendah alih-alih memaksanya menjadi ERROR. Jika pengurutan bisnis diperlukan, tentukan rentang default yang terdokumentasi, catat versi pemetaan, pantau rasio yang tidak diketahui, dan perbaiki semantik sumbernya.
Bisakah sampling mengubah distribusi tingkat keparahan?
Ya. Prioritaskan rekaman yang parah dan event exception, catat keputusan sampling serta penyebut (denominator) input, dan bandingkan distribusi sebelum dan sesudah sampling. Jumlah yang di-sample tidak boleh disajikan sebagai tingkat kesalahan yang sebenarnya tanpa konteks tersebut.
Bagaimana Anda menjaga kueri lama tetap kompatibel?
Pertahankan bidang sumber dan alias lama di lapisan konversi untuk sementara waktu, dan sediakan tampilan atau fungsi kueri berversi. Selama migrasi, lakukan dual-write atau replay peringatan dan laporan hingga perbedaannya dipahami, lalu hentikan penggunaan bidang lama.