Belajar Firecracker - Observability & Troubleshooting

#Pendahuluan

Sistem yang sehat di skala ribuan microVM adalah sistem yang terlihat. Episode 20 membahas observability dan troubleshooting: bagaimana Firecracker melaporkan kondisinya, dan bagaimana kalian men-debug kegagalan — dari error boot sampai restore snapshot yang gagal.

Mengapa episode ini penting? Di dunia container, debugging punya ekosistem yang mapan. Di dunia microVM, semua itu harus dibangun di atas log, metrics, dan serial console Firecracker — dan sebagian besar incident platform serverless berakar pada debugging yang terlalu lama. Menguasai observability berarti mempersingkat waktu pemulihan dari jam menjadi menit.

#Log Firecracker

Log Firecracker keluar ke stderr (atau file yang diarahkan). Level dan format bisa diatur lewat API:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PUT http://localhost/logger \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{
    "level": "Info",
    "log_path": "/logs/firecracker.log"
  }'

Poin penting membaca log:

• Level: Error untuk hanya error, Info untuk siklus hidup normal, Debug untuk troubleshooting mendalam. Naikkan level hanya saat men-debug — Debug berisik dan mahal.
• Ratelimit: Firecracker membatasi kecepatan log untuk mencegah satu VM membanjiri storage. Konfigurasi log_path, level, dan interval ratelimit lewat PUT /logger.
• Format: tiap baris memuat timestamp, level, dan konteks — cocok untuk diparse ke sistem log terpusat.

Contoh baris yang akan kalian lihat saat debug:

Log Firecracker

[2026-08-13T04:00:00.000Z] [INFO] VMM
[2026-08-13T04:00:00.100Z] [WARN] Firecracker

Kebiasaan yang sehat: arahkan log semua VM ke log terpusat (via log_path ke file, lalu di-tail oleh agent), jangan meninggalkan log di host ephemeral.

#Metrics: API /metrics

Firecracker mengekspos metrik dalam format Prometheus di GET /metrics — data siklus hidup yang bisa di-scrape dan di-alert. Ambil contoh:

curl --unix-socket /tmp/firecracker.sock http://localhost/metrics

Metrik yang tersedia mencakup:

• Siklus hidup VM: fc_api_requests, vmm_* state, start_time/end_time.
• Device: jumlah paket dan error pada virtio-net, I/O pada virtio-block, balloon statistics.
• API: jumlah request sukses dan gagal per endpoint.

Pola penggunaan di produksi:

• Scrape berkala ke Prometheus dari semua host, dengan label per host dan per VM.
• Alert pada sinyal bahaya: error API naik, device error, VM restart berlebihan.
• Trend untuk kapasitas: metrik boot time dan restore time di-agregasi per host.

Metrics adalah data objektif yang menjawab "apakah sistem berjalan sehat" — pasangan dari log yang menjawab "mengapa tidak".

#Tracing

Untuk menelusuri alur request end-to-end (dari request masuk → orchestrator → restore → resume), tambahkan konteks tracing di API Firecracker:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PUT http://localhost/metrics/config \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{ "metrics_path": "/metrics", "res_metrics": true }'

Tracing di sini memberi korrelasi antara request API dan operasi internal Firecracker — berguna saat kalian ingin tahu mengapa restore melambat: apakah karena I/O disk snapshot, kompetisi CPU, atau antrian API. Gabungkan dengan tracing orchestrator untuk gambaran menyeluruh.

#Serial Console: Jendela ke Guest

Saat guest bermasalah — boot hang, kernel panic, aplikasi tidak jalan — serial console adalah jendela yang paling jujur:

• Redirect output Firecracker ke pty (episode 4), atau
• Akses langsung dari proses yang jalan.

Di dalam console kalian bisa melihat: log boot kernel, di mana proses berhenti, dan apa yang guest katakan saat gagal. Untuk guest yang punya getty di serial, kalian bahkan bisa login dan menyelidiki lebih dalam. Serial console tidak tergantikan untuk debugging boot — tidak ada dashboard yang bisa menggantikannya.

#Troubleshooting Umum

#Error KVM

• Gejala: Error: KVM not available saat start.
• Urutan cek: /dev/kvm ada? kvm-ok bilang apa? grep -cE 'vmx|svm' /proc/cpuinfo bukan nol? Group kvm punya user non-root?
• Solusi: aktifkan virtualisasi di BIOS, atau jalankan di host dengan nested virtualization.

#Restore Snapshot Gagal

• Gejala: PUT /snapshot/load error.
• Cek pertama: cpu_template dan vcpu_count antara pembuat snapshot dan host tujuan. Ketidakcocokan adalah penyebab nomor satu.
• Cek kedua: drive yang dipakai konsisten (read-only, image sama).
• Cek ketiga: file snapshot dan mem lengkap dan tidak korup (cocokkan hash saat transfer).

#Boot Tidak Selesai

• Gejala: proses jalan, tapi guest tidak menghasilkan output.
• Cek: console=ttyS0 ada di boot args? Kernel uncompressed? Rootfs punya init?

#API Menolak

• Gejala: 409 Conflict setelah start.
• Makna: konfigurasi terkunci pasca boot (episode 4) — buat VM baru atau pakai snapshot.

#Alat Terakhir: firecracker --help dan gdb

Ketika log tidak cukup, dua alat terakhir:

firecracker --help

firecracker --help mencetak seluruh flag proses — termasuk yang tidak ada di dokumentasi utama. Ini sumber kebenaran tentang apa yang bisa dikonfigurasi proses.

Untuk kasus crash yang paling sulit, gdb bisa di-attach ke proses Firecracker untuk melihat backtrace:

sudo gdb -p $(pgrep -f "firecracker" | head -1)

Di dalam gdb, periksa thread dan backtrace untuk memahami titik crash. Ini langkah terakhir dan paling dalam — biasanya dibutuhkan saat menghadapi bug VMM yang belum dikenal.

#Common Pitfalls

• Log di level Debug di produksi: berisik dan mahal; balik ke Info/Error setelah selesai.
• Metrics tanpa alert: data tanpa aksi hanya arsip; pasang alert pada sinyal kritis.
• Mengandalkan log host untuk guest: log boot guest hanya terlihat di serial console — jangan lewatkan.
• Snapshot restore tanpa cek template: penyebab paling umum kegagalan restore.
• Lupa arah log ke sistem terpusat: saat VM mati, log di host ephemeral ikut hilang.

#Penutup

Inti yang harus dibawa pulang:

• Log lewat PUT /logger: level, log_path, dan ratelimit yang bisa diatur.
• Metrics Prometheus di GET /metrics untuk alert dan trend kapasitas.
• Serial console adalah jendela ke guest — wajib untuk debug boot.
• Error KVM, restore gagal, dan boot hang punya urutan cek yang jelas.
• firecracker --help dan gdb adalah alat terakhir saat log tidak cukup.

Di episode 21 selanjutnya kita akan melihat ke belakang layar proyek: Ekosistem rust-vmm & Kolaborasi — berbagi crate seperti kvm-ioctls, vm-memory, dan virtio-devices yang dipakai Firecracker, Cloud Hypervisor, dan crosvm; perkembangan monorepo dan dukungan RISC-V; serta komunitas GitHub, Slack, roadmap, dan governance Firecracker.