Petunjuk dan cakupan
Sebuah perusahaan menghasilkan log teks aplikasi, stdout kontainer, dan event JSON legasi dengan nama field, presisi waktu, serta konvensi tingkat keparahan (severity) yang berbeda-beda. Perusahaan tersebut ingin menerapkan OpenTelemetry Logs Data Model sembari mempertahankan kemampuan pencarian historis dan menghindari tautan TraceId yang menyesatkan. Rancang rencana backfill offline ditambah penulisan ganda (dual-write) secara real-time.
OpenTelemetry memisahkan Timestamp, ObservedTimestamp, TraceId, SpanId, SeverityNumber, Body, Resource, dan Attributes. Migrasi ini merupakan kontrak data yang dapat dilacak, bukan sekadar keputusan untuk memasukkan setiap baris ke dalam Body. Jawaban yang kuat menangani kegagalan parser, zona waktu, duplikasi, field sensitif, dan watermark pemutaran ulang.
Hal yang dievaluasi oleh pewawancara
- Membedakan waktu event, waktu observasi, atribut resource, dan atribut event.
- Merancang pemetaan skema, versi, retensi field yang tidak dikenal, dan jalur kegagalan parsing.
- Menjaga kebenaran dan sifat opsional dari TraceId, SpanId, serta pengenal permintaan (request ID).
- Menangani isolasi tenant, redaksi, duplikasi, perubahan urutan (reordering), dan biaya backfill.
- Memberikan quality gate yang dapat diputar ulang dan direkonsiliasi alih-alih hanya menyebutkan nama alat ETL.
Pertanyaan klarifikasi
- Apakah timestamp legasi berupa waktu lokal, UTC, atau campuran, dan apakah memiliki presisi milidetik atau nanodetik?
- Sumber mana yang memiliki skema stabil, dan mana yang memerlukan parsing berbasis regex atau sampel?
- Apakah TraceId, SpanId, dan ID permintaan dihasilkan oleh aplikasi atau ditebak oleh kolektor?
- Apakah payload mentah harus disimpan, untuk berapa lama, dan siapa yang boleh membacanya?
- Apakah backfill dan dual-write berbagi penyimpanan serta indeks yang sama, dan seberapa besar divergensi kueri yang dapat diterima?
Jawaban 30 detik
Saya akan membuat kontrak pemetaan berversi dan mempertahankan payload mentah beserta status parsing-nya. Timestamp adalah waktu event dan ObservedTimestamp adalah waktu observasi; Resource memuat fakta sumber yang stabil seperti layanan, host, dan tenant, Attributes memuat field event, dan Body menyimpan konten bisnis terstruktur. Saya hanya akan mengisi TraceId dan SpanId dari konteks tepercaya. Backfill dijalankan bersamaan dengan dual-write, rekonsiliasi menggunakan partisi sumber dan waktu, serta kegagalan masuk ke dead letter yang dapat diputar ulang. Quality gate mencakup keberhasilan parsing, kelengkapan field, time skew, duplikasi, kecocokan redaksi, dan ekuivalensi kueri.
Solusi langkah demi langkah
1. Tetapkan kontrak data terlebih dahulu
Tentukan versi parser, field wajib, nilai default, dan kebijakan field tak dikenal untuk setiap sumber. Hasilkan ID event yang stabil dan catat sumber, offset file, atau posisi pesan. Field tak dikenal dapat tetap berada di Attributes atau payload mentah, tetapi tidak boleh hilang begitu saja; perubahan semantik memerlukan peningkatan versi pemetaan.
{
"timestamp": "2026-08-02T02:00:00.123Z",
"observedTimestamp": "2026-08-02T02:00:00.800Z",
"severityNumber": 17,
"severityText": "ERROR",
"body": {"message": "payment declined", "code": "CARD_DECLINED"},
"resource": {"service.name": "checkout", "tenant.id": "t-7"},
"attributes": {"region": "us-east-1"}
}2. Pertahankan semantik waktu
Normalisasikan timestamp yang memiliki zona waktu serta pertahankan string asli dan status parsing. Timestamp adalah saat event terjadi; ObservedTimestamp adalah saat kolektor mengamatinya. Jika waktu event hilang, gunakan waktu observasi hanya sebagai fallback eksplisit dan tandai, sehingga keterlambatan pengumpulan tidak disalahartikan sebagai latensi bisnis. Validasi waktu di masa depan, usia data yang terlalu tua, dan pemotongan presisi.
3. Petakan Resource, Attributes, dan Body
Resource mendeskripsikan entitas yang menghasilkan log, seperti layanan, versi, host, kluster, dan tenant. Attributes mendeskripsikan instans event, seperti wilayah, jenis permintaan, atau grup eksperimen. Body berisi konten terstruktur atau pesan yang belum di-parse. Salah menempatkan field akan mengubah agregasi, pengindeksan, dan biaya, sehingga pemetaan harus mencatat alasan dan konsumen hilir (downstream).
4. Petakan tingkat keparahan dan konteks
Petakan WARN, ERR, dan tingkat numerik legasi ke SeverityNumber sembari mempertahankan SeverityText asli. Terima TraceId, SpanId, dan TraceFlags hanya jika format dan titik injeksi tepercaya. Biarkan konteks yang hilang tetap kosong dengan mencantumkan alasan; jangan pernah mengarang ID trace. ID permintaan dapat menjadi Attribute biasa tetapi tidak boleh ditampilkan sebagai TraceId.
5. Rancang dual-write dan backfill
Jalur real-time menulis ke penyimpanan lama dan baru menggunakan ID event yang sama. Jalur offline membagi file, partisi, atau posisi pesan dan mencatat checkpoint. Kedua jalur berbagi parser dan aturan redaksi yang sama tetapi dapat menggunakan ukuran batch yang berbeda. Setelah backfill, lakukan rekonsiliasi berdasarkan sumber, jendela waktu, dan ID event, lalu alihkan kueri secara bertahap ke model baru.
6. Tangani kegagalan, duplikasi, dan perubahan urutan
Tulis kegagalan parsing ke dead letter yang berisi data mentah, kode kesalahan, dan versi parser; putar ulang dari checkpoint setelah perbaikan. Hapus duplikasi dengan ID event ditambah posisi sumber dan hash konten. Jangan menulis ulang waktu event karena rekaman tiba di luar urutan; biarkan indeks mendukung waktu event dan waktu observasi secara terpisah. Jika identitas tidak pasti, tandai alih-alih menimpanya secara diam-diam.
7. Isolasi, redaksi, dan biaya
Ambil ID tenant dari atribut Resource yang tepercaya, bukan dari input klien sembarangan. Redaksi rahasia, token, dan data pribadi sebelum persistensi, serta catat versi redaksi dan jumlah temuan. Enkripsi payload mentah secara terpisah dengan akses terbatas dan masa retensi lebih singkat. Anggarkan indeks untuk Attributes dengan kardinalitas tinggi agar satu model yang dinormalisasi tidak menimbulkan lonjakan biaya.
8. Quality gate dan rollback
Ambil sampel kueri lama dan baru, lalu bandingkan jumlah event, distribusi keparahan, time skew, dan field kritis. Tetapkan gate pada keberhasilan parsing, kelengkapan field wajib, duplikasi, time skew, luputnya redaksi, dan ekuivalensi kueri. Pertahankan penulisan lama selama fase canary; jika terjadi pergeseran field atau kebocoran tenant, hentikan penulisan baru dan arahkan kembali kueri menggunakan checkpoint tanpa menghapus data mentah yang dapat diputar ulang.
Contoh jawaban yang kuat
Saya akan membagi migrasi menjadi kontrak, parsing, dual-write, backfill, rekonsiliasi, dan cutover. Setiap sumber mendapatkan parser berversi dan ID event yang stabil. Timestamp adalah waktu event dan ObservedTimestamp adalah waktu pengumpulan. Resource menyimpan fakta layanan, host, dan tenant yang stabil; Attributes menyimpan field event; Body menyimpan konten terstruktur; SeverityNumber memetakan level lama; TraceId hanya diterima dari konteks tepercaya.
Selama fase live, penyimpanan lama dan baru menerima event yang sama. Backfill berjalan berdasarkan posisi, dan kegagalan masuk ke dead letter bersama data mentah dan kode kesalahan. Rekonsiliasi berdasarkan ID event dan posisi sembari melacak tingkat perubahan urutan dan duplikasi. Lakukan redaksi sebelum persistensi dan isolasi payload mentah. Lakukan canary pada jumlah event, kelengkapan, time skew, dan hasil kueri; gate yang gagal akan menghentikan writer baru dan memulihkan kueri lama.
Kesalahan umum
- Memasukkan semuanya ke dalam Body → downstream kehilangan semantik resource dan atribut → petakan field berdasarkan model data dan pertahankan field tak dikenal.
- Mengganti waktu event dengan waktu pengumpulan → latensi bisnis menjadi tidak dapat diukur → pertahankan Timestamp dan ObservedTimestamp.
- Mengarang TraceId saat konteks hilang → menciptakan trace palsu → biarkan kosong dan catat alasannya.
- Dual-write tanpa rekonsiliasi → riwayat dan hasil live tidak dapat dibuktikan ekuivalen → rekonsiliasi berdasarkan posisi, ID event, dan jendela waktu.
- Membuang kegagalan parsing → perbaikan parser tidak dapat memperbaiki data historis → gunakan dead letter yang dapat diputar ulang.
- Melakukan persistensi sebelum redaksi → data mentah memiliki jendela paparan yang lebih besar → lakukan redaksi pada ingress terkontrol dan isolasi data asli.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika tidak ada timestamp event?
Gunakan ObservedTimestamp sebagai fallback eksplisit dengan penanda waktu hilang. Jangan menampilkannya sebagai waktu bisnis; laporkan secara terpisah dalam metrik kualitas.
Bagaimana Anda membuktikan TraceId tidak dipalsukan?
Percayai hanya SDK aplikasi atau konteks proksi terkontrol, validasi format dan cakupan, serta perlakukan field klien dengan nama yang sama sebagai Attribute biasa.
Bagaimana Anda menangani duplikasi dari dual-write?
Hasilkan ID event yang stabil dan gunakan posisi sumber ditambah hash konten untuk penulisan idempoten. Jika identitas tetap tidak pasti, pertahankan penanda duplikat dan jelaskan pada saat kueri.
Bagaimana jika arti suatu field berubah selama migrasi?
Tingkatkan versi parser dan skema, pertahankan pemetaan lama dan metadata versi, berikan jendela kompatibilitas, dan uji kueri downstream terhadap kedua versi.
Mengapa perlu mempertahankan payload mentah?
Payload mentah memungkinkan perbaikan parser, investigasi perselisihan data, dan pemutaran ulang. Enkripsi dan batasi aksesnya, audit akses tersebut, persingkat masa retensi, dan pisahkan dari indeks ternormalisasi.