Perintah dan konteks
Sebuah agen observabilitas harus mengukur latensi syscall di berbagai distribusi dan versi kernel. Melakukan kompilasi secara terpisah untuk setiap kernel menciptakan matriks rilis yang sulit dikelola, sementara offset struct yang di-hardcode akan rusak setelah pembaruan. Jelaskan BTF, relokasi CO-RE, dan tanggung jawab libbpf, lalu rancang jalur build, pemuatan, event, dan kompatibilitas yang dapat diverifikasi.
Hal yang diuji oleh pewawancara
- Pemahaman tentang hubungan antara informasi tipe BTF, catatan relokasi kompiler, dan penambalan waktu muat (load-time patching).
- Membedakan portabilitas tata letak dari batasan verifier, helper, kfunc, dan jenis program.
- Merancang siklus hidup event, pengiriman ring-buffer atau perf-buffer, dan pencatatan kehilangan (loss accounting).
- Menangani BTF yang hilang, field yang tidak ada, kapabilitas yang tidak memadai, dan kegagalan pemuatan.
Pertanyaan klarifikasi awal
- Apakah kernel target mengaktifkan BTF dan mengekspos
/sys/kernel/btf/vmlinux? - Jenis probe apa saja yang tersedia—tracepoint, kprobe, fentry, atau LSM—dan apa batasan hak istimewanya?
- Berapa tingkat event, anggaran latensi, batas kehilangan yang ditoleransi, dan model konsumsi user-space?
- Arsitektur, versi kernel, dan lingkungan kontainer apa saja yang harus didukung?
- Jika suatu field tidak ada atau verifier menolak program, apakah agen harus menonaktifkan metrik atau menggunakan probe cadangan (fallback)?
Kerangka jawaban 30 detik
Saya akan mengompilasi satu objek BPF dengan data BTF dan relokasi CO-RE, lalu membiarkan libbpf menambal offset field saat waktu muat dari BTF kernel yang sedang berjalan. Skeleton yang dihasilkan akan mengelola map, program, dan ring buffer sambil memeriksa kapabilitas, BTF, dan jenis program. Field yang hilang atau kegagalan pemuatan akan dicatat dan akan menonaktifkan metrik atau beralih ke tracepoint yang stabil; agen tidak akan pernah mengeluarkan nilai palsu. Tolok ukur (benchmark) akan mencakup beberapa kernel, event yang bersamaan, kehilangan data, dan pemulihan saat pembongkaran (unload).
Jawaban mendalam langkah demi langkah
Langkah 1: Pisahkan tanggung jawab waktu kompilasi dan waktu muat
Kompiler menulis program BPF, informasi tipe, dan catatan relokasi CO-RE ke dalam objek. Pada waktu muat, libbpf menggunakan BTF kernel target untuk menyelesaikan struct, field, dan offset serta memperbarui data langsung (immediates) atau offset instruksi. CO-RE mengurangi build per-kernel, tetapi tidak membuat setiap helper, kfunc, atau jenis program otomatis tersedia.
Langkah 2: Pilih batas probe yang stabil
Pilih tracepoint atau fentry yang stabil dan konfirmasikan field event yang diekspos oleh kernel target. Kprobe mencakup lebih banyak jalur tetapi lebih bergantung pada simbol dan tata letak parameter. Nyatakan akses field dengan makro CO-RE alih-alih offset tetap. Baca hanya field yang diperlukan untuk mengurangi beban kerja verifier dan ukuran event.
Langkah 3: Rancang struktur event dan transport
Catat pid, timestamp, identitas syscall, dan data latensi minimum di BPF, lalu kirimkan melalui ring buffer atau perf buffer. Gunakan event berukuran tetap atau field versi eksplisit, serta validasi panjang dan versi di user space. Lacak kehilangan per CPU, proses, dan antrean; jangan pernah mengubah luapan buffer secara diam-diam menjadi latensi nol.
Langkah 4: Jadikan batasan verifier bagian dari desain
Pemeriksaan batas (bounds checks), batas loop, tipe pointer, dan nilai kembalian helper harus memenuhi ketentuan verifier. Pindahkan penguraian yang kompleks ke user space dan hindari penelusuran yang tidak dapat dibuktikan di BPF. Pastikan definisi map yang dihasilkan oleh kompiler dan skeleton cocok dengan akses program. Simpan ringkasan kegagalan verifier dan versi kernel di log untuk diagnostik.
Langkah 5: Tangani perbedaan BTF dan field
Periksa apakah BTF target dapat dibaca dan gunakan field CO-RE opsional atau feature probe untuk mendeteksi keberadaan field. Jika perubahan tata letak menyebabkan relokasi gagal, nonaktifkan metrik atau pilih tracepoint yang kompatibel; jangan mengisi field yang tidak dapat dibaca dengan nilai default lalu melaporkan latensi yang presisi. Validasi perbedaan arsitektur dalam matriks CI multi-kernel.
Langkah 6: Rancang jalur build dan rilis
Kunci versi clang, libbpf, dan pembuat skeleton, hasilkan objek yang membawa BTF, dan catat ID build-nya. Distribusikan loader user-space, objek BPF, dan persyaratan kapabilitas minimum. Jalankan pemeriksaan mandiri sebelum memuat. Penerapan kontainer harus menyatakan filesystem BPF, hak istimewa, dan pengaturan kernel yang diperlukan serta memberikan alasan kegagalan yang dapat ditindaklanjuti.
Langkah 7: Verifikasi performa, kebenaran, dan rollback
Bandingkan nilai field dan jumlah event dengan alat independen di berbagai distribusi, arsitektur, dan kernel. Uji beban (stress test) CPU, memori, kehilangan ring-buffer, jeda user-space, dan tail latency pada tingkat event yang tinggi. Simpan objek lama atau probe yang stabil sebagai jalur rollback dan konfirmasikan bahwa tautan, map, dan thread dilepaskan saat dibongkar.
Contoh jawaban berkualitas tinggi
Saya akan mengompilasi satu objek yang berisi relokasi BTF dan CO-RE dan membiarkan libbpf menambal offset dari BTF kernel target. Probe akan memprioritaskan tracepoint atau fentry yang stabil; BPF akan memancarkan event kecil berversi, dan skeleton user-space akan mendekodekannya melalui ring buffer sambil menghitung kehilangan. Pemeriksaan awal akan mencakup BTF, jenis program, kemampuan helper, dan keberadaan field. Kegagalan relokasi atau verifier akan menonaktifkan metrik atau mengalihkan probe, tanpa memalsukan data. CI akan mencakup arsitektur, kernel, tingkat event tinggi, dan pemulihan saat pembongkaran, dengan probe lama dipertahankan untuk rollback.
Kesalahan umum
- Menganggap CO-RE sebagai kompatibilitas untuk setiap helper, kfunc, dan batasan verifier.
- Meng-hardcode offset struct dan mengabaikan BTF serta relokasi.
- Menghilangkan pemeriksaan versi dan panjang event serta memperlakukan data yang terpotong sebagai data yang valid.
- Mengabaikan kehilangan buffer dan melaporkan celah pengamatan sebagai latensi nol.
- Mengisi field yang hilang dengan nilai default dan menyembunyikan kegagalan kompatibilitas.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Kapan relokasi CO-RE terjadi?
Kompilasi menulis catatan relokasi ke dalam objek BPF. Pada waktu muat, libbpf menyelesaikannya dengan BTF kernel target dan menambal informasi field. Offset tidak dihitung ulang untuk setiap event saat runtime.
Pertanyaan lanjutan 2: Bisakah dijalankan tanpa BTF vmlinux?
Itu tergantung pada BTF yang tersedia, jenis probe, distribusi, dan kemampuan libbpf. Pemeriksaan saat startup harus menentukan apa yang aman; jika field tidak dapat diselesaikan, nonaktifkan program atau gunakan probe stabil yang tidak bergantung padanya.
Pertanyaan lanjutan 3: Mengapa tidak menggunakan kprobe di mana saja?
Kprobe fleksibel tetapi lebih bergantung pada simbol, parameter, dan inlining, sehingga semantik pembaruan kurang stabil. Tracepoint atau fentry dapat mengurangi beban pemeliharaan meskipun tetap memerlukan pemeriksaan ketersediaan.
Pertanyaan lanjutan 4: Bagaimana Anda membuktikan bahwa tidak ada laporan yang terlewat?
Rekonsiliasi jumlah event BPF, kehilangan ring-buffer, konsumsi user-space, dan jumlah syscall independen berdasarkan CPU dan jendela waktu. Setiap ketidakcocokan harus muncul sebagai status hilang atau terdegradasi, bukan diam-diam menjadi nol.
Pertanyaan lanjutan 5: Bagaimana cara men-debug penolakan verifier?
Simpan log loader, versi kernel, arsitektur target, ID BTF, dan ringkasan verifier. Persempit masalah ke batas pointer, batas loop, penggunaan helper, atau definisi map dengan pembuat ulang minimal (minimal reproducer), lalu jalankan kembali matriks multi-kernel setelah memperbaikinya.