Petunjuk dan ruang lingkup
Pewawancara mungkin bertanya: “Rancang pipeline log OpenTelemetry yang mendukung korelasi trace. Jelaskan model data, backpressure, isolasi tenant, dan pemulihan (recovery).”
Sinyal yang dinilai adalah apakah Anda dapat mengubah event aplikasi menjadi telemetri yang terkelola dengan baik. OpenTelemetry Logs Data Model memisahkan Timestamp, TraceId, SpanId, SeverityNumber, Body, Resource, dan Attributes; OTLP memungkinkan log berpindah secara hop-by-hop melalui agent, Collector, dan backend. Tantangannya adalah mempertahankan semantik, kapasitas, dan batasan keamanan, bukan sekadar menggambar satu garis Kafka.
Apa yang diuji oleh pewawancara
- Apakah Anda memisahkan tanggung jawab Resource, Attributes, Body, dan Trace Context.
- Apakah Anda dapat merancang jalur yang andal di seluruh aplikasi, agent, Collector, antrean, dan backend.
- Apakah Anda menangani lonjakan backpressure, batching, percobaan ulang (retry), penghapusan berdasarkan prioritas (priority drop), dan buffering disk.
- Apakah Anda mencegah paparan lintas-tenant dan meredaksi rahasia (secrets) serta data pribadi.
- Apakah Anda menjelaskan penanganan duplikasi, pengurutan, sampling, dan pengalaman kueri saat TraceId tidak ada.
Pertanyaan klarifikasi
- Apakah sumber log berasal dari SDK, file yang sudah ada, stdout kontainer, atau kombinasi?
- Berapa target jumlah tenant, throughput, retensi, dan latensi kueri?
- Apakah aplikasi menyuntikkan TraceId secara konsisten, dan apakah kunci korelasi diizinkan saat TraceId tidak ada?
- Field mana saja yang berisi data pribadi, rahasia, atau konten sensitif bisnis, dan di mana redaksi harus dilakukan?
- Selama kegagalan backend, level log mana yang boleh di-drop dan berapa banyak data pemutaran ulang (replay) yang diperlukan setelah pemulihan?
Jawaban 30 detik
Anda dapat mengatakan:
Saya akan menggunakan jalur berlapis dari receiver aplikasi atau file ke Collector lokal, lalu ke antrean dan backend. Setiap record mempertahankan waktu, tingkat keparahan (severity), Body, Resource, dan Attributes, serta menyertakan TraceId dan SpanId jika konteksnya ada. Collector melakukan batching, pembatasan laju (rate limiting), redaksi, dan routing; antrean serta buffer disk menyerap variasi latensi (jitter) backend. Identitas tenant dimasukkan ke dalam atribut Resource dan indeks otorisasi yang tepercaya. Saat terjadi lonjakan beban, drop atau lakukan sampling pada log debug terlebih dahulu, kemudian kelola retry, duplikasi, dan pembacaan pemulihan.
Penalaran langkah demi langkah
Tentukan satu kontrak record
Jangan jadikan teks baris tak terstruktur sebagai satu-satunya kontrak. Record logis dapat terlihat 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 mendeskripsikan entitas yang memancarkan log, Attributes mendeskripsikan terjadinya suatu event, dan Body mempertahankan konten terstruktur. Bandingkan keparahan menggunakan SeverityNumber sambil tetap mempertahankan SeverityText sumber untuk tampilan.
Rancang pengumpulan dan transportasi
SDK atau receiver file mengonversi record ke OTLP. Agent pada node melakukan batching dan menerapkan batas awal; Collector mengurai, memperkaya data Resource, meredaksi, merutekan, dan mengekspor. OTLP mendukung Collector perantara, sehingga jalur yang panjang memerlukan batas waktu (timeout), autentikasi, dan kompresi yang eksplisit. Antrean bersifat opsional, tetapi dapat memberikan buffering persisten dan batas kuota tenant saat throughput backend tidak stabil.
Tangani backpressure dan kelas data
Tetapkan batas laju, batch, memori, dan disk per-tenant serta per-service. Saat backend melambat, jeda ekspor berprioritas rendah sambil tetap mempertahankan event error, audit, dan keamanan; lakukan sampling atau drop pada debug. Retry memerlukan exponential backoff dan batas waktu retensi maksimum untuk menghindari badai retry (retry storm). Catat rentang batch yang gagal untuk pemutaran ulang (replay) dan gunakan idempotensi atau deduplikasi backend untuk mengurangi duplikat.
Amankan, isolasi, dan korelasikan kueri
Hapus rahasia, token, dan data pribadi sejak dini di edge atau Collector. Suntikkan identitas tenant dari sumber Resource yang tepercaya; jangan menerima penggantian sepihak dari klien. Partisi indeks berdasarkan tenant dan waktu, dengan indeks korelasi opsional untuk TraceId dan SpanId. Log tanpa TraceId tetap dapat dikueri berdasarkan service, waktu, dan pengidentifikasi permintaan; jangan pernah membuat TraceId palsu.
Contoh jawaban berkualitas tinggi
Saya akan membagi desain menjadi lapisan kontrak record, pengumpulan, buffering, pemrosesan, dan kueri. Record mengikuti OpenTelemetry Logs Data Model untuk waktu, severity, Body, Resource, dan Attributes, serta menambahkan TraceId dan SpanId ketika aplikasi memiliki konteks. SDK atau filelog receiver mengirim data ke Collector di node; Collector melakukan batching, redaksi, penegakan kuota tenant, dan perutean melalui OTLP, dengan antrean persisten per-tenant bila diperlukan. Jitter backend diserap oleh buffer memori dan disk; jika batas kapasitas terlampaui, lakukan drop secara berurutan mulai dari debug, info, error, hingga audit sambil mengukur drop rate dan usia record tertua. Indeks kueri diisolasi berdasarkan tenant dan waktu, dan korelasi TraceId mempercepat investigasi tanpa merekayasa konteks. Pemulihan menggunakan rentang batch, backoff, dan deduplikasi idempoten; log audit dan keamanan memiliki kebijakan retensi dan akses yang terpisah.
Kesalahan umum
- Menempatkan semua field ke dalam Body dan kehilangan semantik Resource, Attributes, dan Trace Context.
- Hanya menggambar garis langsung dari aplikasi ke backend tanpa agent, Collector, antrean, atau buffer disk.
- Melakukan retry tanpa henti saat backend mengalami kegagalan hingga memori habis dan menyebabkan pemadaman beruntun (cascading outage).
- Membiarkan klien mengirimkan atribut tenant secara langsung sehingga mencemari indeks lintas-tenant.
- Menghasilkan ID trace acak untuk log yang tidak memiliki konteks sehingga menyesatkan investigasi.
- Membahas throughput tanpa menyertakan metrik priority drop, redaksi, duplikasi, dan pemulihan.
Pertanyaan lanjutan dan jawabannya
1. Apa yang Anda lakukan ketika TraceId tidak ada?
Pertahankan log asli dan tandai konteksnya sebagai tidak ada. Gunakan pengidentifikasi service, waktu, dan permintaan yang dapat diverifikasi untuk korelasi. Isi TraceId hanya jika aplikasi atau proxy tepercaya menyediakannya; jangan pernah membuatnya sendiri.
2. Bagaimana cara mencegah kebocoran data rahasia (secrets)?
Terapkan aturan berbasis field dan redaksi pola sejak dini di SDK, agent, atau Collector, tolak format rahasia yang jelas, dan tegakkan kontrol akses backend tingkat tenant. Setiap retensi data mentah yang di-sampling membutuhkan isolasi dan audit yang lebih ketat.
3. Kapan tindakan drop log dapat diterima?
Tentukan klasifikasi bisnis terlebih dahulu: log keamanan, audit, dan error kritis biasanya harus dipertahankan; debug dan field diagnostik dengan kardinalitas tinggi dapat di-sampling. Catat alasan, tenant, rentang waktu, dan jumlah log yang di-drop untuk setiap kejadian agar tekanan kapasitas dapat dijelaskan dan memicu peringatan (alert).