Skop dan gesaan
Sebuah syarikat mengeluarkan log teks aplikasi, stdout kontena, dan peristiwa JSON legasi dengan nama medan, ketepatan masa, dan konvensyen tahap keterukan (severity) yang berbeza. Syarikat tersebut mahukan OpenTelemetry Logs Data Model sambil mengekalkan carian sejarah dan mengelakkan pautan TraceId yang mengelirukan. Reka bentuk pelan pengisian semula (backfill) luar talian berserta penulisan dwi (dual-write) masa nyata.
OpenTelemetry memisahkan Timestamp, ObservedTimestamp, TraceId, SpanId, SeverityNumber, Body, Resource, dan Attributes. Migrasi ini merupakan satu kontrak data yang boleh dijejak, bukannya keputusan untuk meletakkan setiap baris ke dalam Body. Jawapan yang kukuh menangani kegagalan penghurai (parser), zon masa, penduaan, medan sensitif, dan penanda aras (watermark) main semula.
Perkara yang dinilai oleh penemu duga
- Membezakan masa peristiwa, masa pemerhatian, atribut sumber, dan atribut peristiwa.
- Merekabentuk pemetaan skema, versi, pengekalan medan tidak diketahui, dan laluan kegagalan penghuraian.
- Mengekalkan kebenaran dan kebolehan pilihan TraceId, SpanId, dan pengecam permintaan.
- Mengendalikan pengasingan penyewa, pemadaman maklumat sensitif (redaction), penduaan, penyusunan semula, dan kos backfill.
- Memberikan pintu kualiti yang boleh dimainkan semula dan diselaraskan berbanding hanya menamakan alat ETL.
Soalan penjelasan
- Adakah cap masa legasi mengikut masa tempatan, UTC, atau bercampur, dan adakah ia berketepatan milisaat atau nanosaat?
- Sumber manakah yang mempunyai skema stabil, dan manakah yang memerlukan penghuraian regex atau berasaskan sampel?
- Adakah TraceId, SpanId, dan ID permintaan dihasilkan oleh aplikasi atau diteka oleh pengumpul (collector)?
- Adakah muatan mentah (raw payloads) mesti dikekalkan, untuk berapa lama, dan siapa yang boleh membacanya?
- Adakah backfill dan penulisan dwi berkongsi storan dan indeks yang sama, dan berapa banyak perbezaan pertanyaan yang boleh diterima?
Jawapan 30 saat
Saya akan mencipta kontrak pemetaan berversi dan mengekalkan muatan mentah bersama status penghuraian. Timestamp ialah masa peristiwa dan ObservedTimestamp ialah masa pemerhatian; Resource memegang fakta sumber yang stabil seperti perkhidmatan, hos, dan penyewa, Attributes memegang medan peristiwa, dan Body menyimpan kandungan perniagaan yang berstruktur. Saya hanya akan mengisi TraceId dan SpanId daripada konteks yang dipercayai. Backfill berjalan seiring dengan penulisan dwi, penyelarasan menggunakan pembahagian sumber dan masa, dan kegagalan dimasukkan ke dalam surat mati (dead letters) yang boleh dimainkan semula. Pintu kualiti meliputi kejayaan penghuraian, kelengkapan medan, kepincangan masa (time skew), penduaan, padanan pemadaman sensitif, dan kesetaraan pertanyaan.
Penyelesaian langkah demi langkah
1. Tetapkan kontrak data terlebih dahulu
Tentukan versi penghurai, medan yang diperlukan, nilai lalai, dan dasar medan tidak diketahui bagi setiap sumber. Hasilkan ID peristiwa yang stabil dan rekodkan sumber, ofset fail, atau kedudukan mesej. Medan tidak diketahui boleh kekal dalam Attributes atau muatan mentah, tetapi tidak boleh hilang secara senyap; 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. Kekalkan semantik masa
Normalkan cap masa peka zon masa dan kekalkan rentetan asal serta status penghuraian. Timestamp ialah waktu peristiwa berlaku; ObservedTimestamp ialah waktu pengumpul memerhatikannya. Jika masa peristiwa tiada, gunakan masa pemerhatian hanya sebagai sandaran eksplisit dan tandakannya, supaya kelewatan pengumpulan tidak disalah anggap sebagai pendaman perniagaan. Sahkan masa masa hadapan, usia yang terlalu lama, dan pemotongan ketepatan.
3. Petakan Resource, Attributes, dan Body
Resource menerangkan entiti yang menghasilkan log, seperti perkhidmatan, versi, hos, kluster, dan penyewa. Attributes menerangkan tika (instance) peristiwa, seperti rantau, jenis permintaan, atau kumpulan eksperimen. Body mengandungi kandungan berstruktur atau mesej yang tidak dihuraikan. Salah meletakkan medan akan mengubah pengagregatan, pengindeksan, dan kos, jadi pemetaan harus merekodkan sebab dan pengguna hiliran.
4. Petakan keterukan dan konteks
Petakan WARN, ERR, dan tahap berangka legasi kepada SeverityNumber sambil mengekalkan SeverityText asal. Terima TraceId, SpanId, dan TraceFlags hanya apabila format dan titik suntikan dipercayai. Biarkan konteks yang hilang kosong dengan menyatakan sebab; jangan sekali-kali mencipta ID surih palsu. ID permintaan boleh menjadi Attribute biasa tetapi tidak boleh dipersembahkan sebagai TraceId.
5. Reka bentuk penulisan dwi dan backfill
Laluan masa nyata menulis ke storan lama dan baharu dengan ID peristiwa yang sama. Laluan luar talian menghiris fail, partisi, atau kedudukan mesej dan merekodkan titik pemeriksaan (checkpoints). Kedua-dua laluan berkongsi penghurai dan peraturan pemadaman sensitif yang sama tetapi boleh menggunakan saiz kelompok yang berbeza. Selepas backfill, selaraskan mengikut sumber, tetingkap masa, dan ID peristiwa, kemudian alihkan pertanyaan secara beransur-ansur ke model baharu.
6. Kendalikan kegagalan, penduaan, dan penyusunan semula
Tulis kegagalan penghuraian ke dalam dead letters yang mengandungi data mentah, kod ralat, dan versi penghurai; mainkannya semula dari titik pemeriksaan selepas pembetulan dibuat. Nyahduplikasi dengan ID peristiwa berserta kedudukan sumber dan cincangan (hash) kandungan. Jangan tulis semula masa peristiwa hanya kerana rekod tiba di luar urutan; biarkan indeks menyokong masa peristiwa dan masa pemerhatian secara berasingan. Jika identiti tidak pasti, tandakannya daripada menulis ganti secara senyap.
7. Pengasingan, pemadaman maklumat sensitif, dan kos
Ambil ID penyewa daripada atribut Resource yang dipercayai, bukan daripada input klien sebarangan. Padamkan rahsia, token, dan data peribadi sebelum pengekalan kekal (persistence), dengan merekodkan versi pemadaman dan bilangan padanan. Enkripsi muatan mentah secara berasingan dengan akses terhad dan tempoh simpanan yang lebih pendek. Peruntukkan bajet indeks untuk Attributes berkardinaliti tinggi supaya satu model yang dinormalkan tidak menghasilkan lonjakan kos di luar kawalan.
8. Pintu kualiti dan pengunduran (rollback)
Ambil sampel pertanyaan lama dan baharu serta bandingkan bilangan peristiwa, taburan keterukan, kepincangan masa, dan medan kritikal. Tetapkan pintu kualiti pada kejayaan penghuraian, kelengkapan medan yang diperlukan, penduaan, kepincangan masa, keciciran pemadaman maklumat, dan kesetaraan pertanyaan. Kekalkan penulisan lama semasa fasa canary; sekiranya berlaku hanyutan medan atau kebocoran penyewa, hentikan penulisan baharu dan halakan pertanyaan kembali menggunakan titik pemeriksaan tanpa memadam data mentah yang boleh dimainkan semula.
Contoh jawapan yang kukuh
Saya akan membahagikan migrasi kepada kontrak, penghuraian, penulisan dwi, backfill, penyelarasan, dan peralihan akhir (cutover). Setiap sumber mendapat penghurai berversi dan ID peristiwa yang stabil. Timestamp ialah masa peristiwa dan ObservedTimestamp ialah masa pengumpulan. Resource menyimpan fakta perkhidmatan, hos, dan penyewa yang stabil; Attributes menyimpan medan peristiwa; Body menyimpan kandungan berstruktur; SeverityNumber memetakan tahap lama; TraceId hanya diterima daripada konteks yang dipercayai.
Semasa fasa langsung, storan lama dan baharu menerima peristiwa yang sama. Backfill dijalankan mengikut kedudukan, dan kegagalan dihantar ke dead letters bersama data mentah dan kod ralat. Selaraskan mengikut ID peristiwa dan kedudukan sambil menjejaki kadar susunan semula dan penduaan. Lakukan pemadaman maklumat sensitif sebelum persistensi dan asingkan muatan mentah. Lakukan ujian canary terhadap bilangan peristiwa, kelengkapan, kepincangan masa, dan hasil pertanyaan; pintu kualiti yang gagal akan menghentikan penulis baharu dan memulihkan pertanyaan lama.
Kesilapan biasa
- Meletakkan segalanya dalam Body → pengguna hiliran kehilangan semantik sumber dan atribut → petakan medan mengikut model data dan kekalkan medan tidak diketahui.
- Menggantikan masa peristiwa dengan masa pengumpulan → pendaman perniagaan menjadi tidak dapat diukur → kekalkan kedua-dua Timestamp dan ObservedTimestamp.
- Mencipta TraceId palsu apabila konteks tiada → menghasilkan surih palsu → biarkan kosong dan rekodkan sebabnya.
- Penulisan dwi tanpa penyelarasan → sejarah dan hasil langsung tidak dapat dibuktikan setara → selaraskan mengikut kedudukan, ID peristiwa, dan tetingkap masa.
- Menggugurkan kegagalan penghuraian → pembetulan penghurai tidak dapat membaiki data sejarah → gunakan dead letters yang boleh dimainkan semula.
- Mengekalkan data sebelum pemadaman maklumat sensitif → data mentah mempunyai tetingkap pendedahan yang lebih luas → lakukan pemadaman pada pintu masuk (ingress) terkawal dan asingkan data asal.
Soalan susulan dan jawapan
Bagaimana jika tiada cap masa peristiwa?
Gunakan ObservedTimestamp sebagai sandaran eksplisit dengan penanda masa hilang. Jangan persembahkannya sebagai masa perniagaan; laporkannya secara berasingan dalam metrik kualiti.
Bagaimanakah anda membuktikan bahawa TraceId tidak direka-reka?
Percayai hanya SDK aplikasi atau konteks proksi terkawal, sahkan format dan skop, serta anggap medan klien yang mempunyai nama yang sama sebagai Attribute biasa.
Bagaimanakah anda mengendalikan penduaan daripada penulisan dwi?
Hasilkan ID peristiwa yang stabil dan gunakan kedudukan sumber serta cincangan kandungan untuk penulisan idempoten. Jika identiti masih tidak pasti, kekalkan penanda pendua dan jelaskannya pada masa pertanyaan.
Bagaimana jika makna medan berubah semasa migrasi?
Tingkatkan versi penghurai dan skema, kekalkan pemetaan lama serta metadata versi, sediakan tetingkap keserasian, dan uji pertanyaan hiliran terhadap kedua-dua versi.
Mengapa perlu mengekalkan muatan mentah?
Ia membolehkan pembetulan penghurai, siasatan pertikaian data, dan main semula. Enkripsikannya dan sekat akses, audit akses tersebut, pendekkan tempoh simpanan, dan asingkannya daripada indeks ternormal.