Gesaan dan skop
Penemu duga mungkin bertanya: “Reka bentuk saluran log OpenTelemetry yang menyokong korelasi jejak. Terangkan model data, tekanan balik, pengasingan penyewa, dan pemulihan.”
Isyarat yang dinilai ialah sama ada anda boleh menukar peristiwa aplikasi kepada telemetri yang ditadbir. OpenTelemetry Logs Data Model mengasingkan Timestamp, TraceId, SpanId, SeverityNumber, Body, Resource, dan Attributes; OTLP membolehkan log bergerak langkah demi langkah (hop by hop) melalui ejen, Collector, dan bahagian belakang (backend). Cabarannya adalah untuk mengekalkan semantik, kapasiti, dan sempadan keselamatan, bukan sekadar melukis satu garisan Kafka.
Perkara yang diuji oleh penemu duga
- Sama ada anda mengasingkan tanggungjawab Resource, Attributes, Body, dan Trace Context.
- Sama ada anda boleh mereka bentuk laluan yang boleh dipercayai merentasi aplikasi, ejen, Collector, barisan gilir (queue), dan bahagian belakang.
- Sama ada anda mengendalikan tekanan balik lonjakan, pemprosesan kelompok (batching), percubaan semula (retries), pengguguran mengikut keutamaan, dan penimbalan cakera.
- Sama ada anda menghalang pendedahan rentas penyewa dan menyunting rahsia serta data peribadi.
- Sama ada anda menerangkan penduaan, susunan, persampelan, dan pengalaman pertanyaan apabila TraceId tiada.
Soalan penjelasan
- Adakah sumber terdiri daripada SDK, fail sedia ada, stdout bekas (container), atau gabungan?
- Apakah sasaran bilangan penyewa, daya pemprosesan (throughput), pengekalan, dan kependaman pertanyaan?
- Adakah aplikasi menyuntik TraceId secara konsisten, dan adakah kunci korelasi dibenarkan apabila ia tiada?
- Medan manakah yang mengandungi data peribadi, rahsia, atau kandungan sensitif perniagaan, dan di manakah penyuntingan mesti dilakukan?
- Semasa kegagalan bahagian belakang, tahap manakah yang boleh digugurkan dan berapa banyak main semula (replay) yang diperlukan selepas pemulihan?
Jawapan 30 saat
Anda boleh menjawab:
Saya akan menggunakan laluan berlapis daripada penerima aplikasi atau fail ke Collector tempatan, kemudian ke barisan gilir dan bahagian belakang. Setiap rekod mengekalkan masa, tahap keterukan (severity), Body, Resource, dan Attributes, serta menyertakan TraceId dan SpanId apabila konteks wujud. Collector mengelompokkan, mengehadkan kadar, menyunting, dan menghalakan; barisan gilir dan penimbal cakera menyerap variasi kependaman (jitter) bahagian belakang. Identiti penyewa dimasukkan ke dalam atribut Resource dan indeks kebenaran yang dipercayai. Semasa lonjakan beban, gugurkan atau sampel debug terlebih dahulu, kemudian urus percubaan semula, penduaan, dan bacaan pemulihan.
Penaakulan langkah demi langkah
Tentukan satu kontrak rekod
Jangan jadikan baris yang tidak berstruktur sebagai satu-satunya kontrak. Rekod logik boleh kelihatan seperti ini:
{
"timestamp": "2026-08-01T10:00:00Z",
"traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
"spanId": "00f067aa0ba902b7",
"severityNumber": 17,
"severityText": "ERROR",
"body": {"message": "payment declined", "code": "CARD_DECLINED"},
"resource": {"service.name": "checkout", "tenant.id": "t-7"},
"attributes": {"region": "us-east-1"}
}Resource menerangkan entiti yang memancarkan log, Attributes menerangkan kejadian peristiwa, dan Body mengekalkan kandungan berstruktur. Bandingkan tahap keterukan dengan SeverityNumber sambil mengekalkan SeverityText sumber untuk paparan.
Reka bentuk pengumpulan dan pengangkutan
SDK atau penerima fail menukar rekod kepada OTLP. Ejen nod mengelompokkan dan menggunakan had awal; Collector menghuraikan, memperkaya data Resource, menyunting, menghalakan, dan mengeksport. OTLP menyokong Collector perantaraan, jadi laluan yang panjang memerlukan tamat masa (timeout), pengesahan, dan pemampatan yang jelas. Barisan gilir adalah pilihan, tetapi ia boleh menyediakan penimbalan tahan lama dan sempadan kuota penyewa apabila daya pemprosesan bahagian belakang tidak stabil.
Kendalikan tekanan balik dan kelas data
Tetapkan had kadar, kelompok, memori, dan cakera bagi setiap penyewa dan setiap perkhidmatan. Apabila bahagian belakang menjadi perlahan, jedakan eksport keutamaan rendah sambil mengekalkan peristiwa ralat, audit, dan keselamatan; sampel atau gugurkan debug. Percubaan semula memerlukan penangguhan eksponen (exponential backoff) dan masa pengekalan maksimum untuk mengelakkan ribut percubaan semula (retry storms). Catat julat kelompok yang gagal untuk main semula dan gunakan keidempotanan atau penyahduplikasian bahagian belakang untuk mengurangkan penduaan.
Lindungi, asingkan, dan korelasi pertanyaan
Alih keluar rahsia, token, dan data peribadi lebih awal di pinggir atau Collector. Suntik identiti penyewa daripada sumber Resource yang dipercayai; jangan terima penggantian klien yang sewenang-wenangnya. Bahagikan indeks mengikut penyewa dan masa, dengan indeks korelasi TraceId dan SpanId pilihan. Log tanpa TraceId kekal boleh ditanya mengikut perkhidmatan, masa, dan pengecam permintaan; jangan sekali-kali mencipta TraceId palsu.
Contoh jawapan berkualiti tinggi
Saya akan membahagikan reka bentuk kepada lapisan kontrak rekod, pengumpulan, penimbalan, pemprosesan, dan pertanyaan. Rekod mematuhi OpenTelemetry Logs Data Model untuk masa, keterukan, Body, Resource, dan Attributes, dengan menambahkan TraceId dan SpanId apabila aplikasi mempunyai konteks. SDK atau penerima filelog menghantar data ke Collector nod; Collector mengelompokkan, menyunting, menguatkuasakan kuota penyewa, dan menghalakan melalui OTLP, dengan barisan gilir tahan lama bagi setiap penyewa apabila diperlukan. Jitter bahagian belakang diserap oleh penimbal memori dan cakera; apabila belanjawan melebihi had, gugurkan mengikut urutan debug, info, error, dan audit sambil mengukur kadar pengguguran dan usia rekod tertua. Indeks pertanyaan diasingkan mengikut penyewa dan masa, dan korelasi TraceId mempercepatkan siasatan tanpa mereka-reka konteks. Pemulihan menggunakan julat kelompok, penangguhan (backoff), dan penyahduplikasian idempoten; log audit dan keselamatan mempunyai dasar pengekalan dan akses yang berasingan.
Kesilapan lazim
- Memasukkan setiap medan ke dalam Body dan kehilangan semantik Resource, Attributes, dan Trace Context.
- Hanya melukis garisan dari aplikasi ke bahagian belakang tanpa ejen, Collector, barisan gilir, atau penimbal cakera.
- Mencuba semula tanpa henti semasa kegagalan bahagian belakang sehingga memori habis dan gangguan melarat (cascading outage).
- Membenarkan klien menyerahkan atribut penyewa secara langsung dan mencemarkan indeks rentas penyewa.
- Menjana ID jejak rawak untuk log yang tiada konteks dan mengelirukan siasatan.
- Membincangkan daya pemprosesan tanpa metrik pengguguran keutamaan, penyuntingan, penduaan, dan pemulihan.
Soalan susulan dan jawapan
1. Apakah yang anda lakukan apabila TraceId tiada?
Kekalkan log asal dan tandakan konteks sebagai tiada. Gunakan perkhidmatan, masa, dan pengecam permintaan yang boleh disahkan untuk korelasi. Masukkan TraceId hanya apabila aplikasi atau proksi yang dipercayai membekalkannya; jangan sekali-kali mereka-reka nilai tersebut.
2. Bagaimanakah anda menghalang kebocoran rahsia?
Gunakan peraturan medan dan penyuntingan corak lebih awal dalam SDK, ejen, atau Collector, tolak format rahsia yang jelas, dan kuatkan kawalan akses bahagian belakang peringkat penyewa. Sebarang pengekalan data mentah yang disampel memerlukan pengasingan dan audit yang lebih ketat.
3. Bilakah pengguguran log boleh diterima?
Tentukan kelas perniagaan terlebih dahulu: log keselamatan, audit, dan ralat kritikal biasanya dikekalkan; debug dan medan diagnostik berkardinaliti tinggi boleh disampel. Catat sebab, penyewa, julat masa, dan bilangan bagi setiap pengguguran supaya tekanan kapasiti dapat dijelaskan dan mencetuskan amaran.