Tutorial Parca eBPF: Continuous Profiling CPU & Memori Server Linux VPS

Bayangkan jam dua malam HP kamu bergetar kencang. PagerDuty meledak mengirim peringatan darurat: penggunaan CPU pada VPS Linux production tembus 100%, dan latency API melonjak drastis dari 50 milidetik menjadi 5 detik. Kamu buru-buru membuka dashboard Grafana. Grafik CPU cuma menampilkan garis lurus di batas atas, tapi log aplikasi bersih tanpa error sama sekali. Prometheus cuma memberi tahu bahwa server sedang sekarat, tapi tidak tahu baris kode mana yang bikin CPU terbakar.

Skenario horor ini sering memaksa engineer menebak-nebak penyebab masalah. Memasang profiler tradisional di lingkungan production kerap menjadi pilihan sulit karena overhead resource yang tinggi dan keharusan menghentikan aplikasi saat mengambil dump heap. Di sinilah teknologi continuous profiling berbasis eBPF seperti Parca hadir membawa pendekatan baru yang jauh lebih cerdas.

Keterbatasan Observability Tradisional dan Masalah Overhead Profiler

Tiga pilar observability—metrics, logs, dan traces—memiliki kelemahan mendasar ketika berhadapan dengan masalah performa yang samar. Metrics memberi tahu kapan CPU membengkak, logs mencatat kejadian yang sudah diperkirakan sebelumnya, dan distributed tracing melacak alur request antar service. Namun, tidak ada satu pun dari ketiganya yang dapat menunjuk langsung fungsi spesifik mana di dalam kode backend yang mengonsumsi siklus CPU terbanyak saat lonjakan traffic terjadi.

Metode profiling tradisional biasanya mengandalkan library internal aplikasi, seperti pprof pada Go, async-profiler pada Java, atau cProfile pada Python. Cara kerja profiler tingkat aplikasi ini memiliki beberapa kelemahan di lingkungan production:

• Modifikasi Kode dan Restart: Kamu harus memasukkan SDK profiler ke dalam codebase, mengonfigurasi endpoint HTTP khusus, lalu menyebarkan ulang (re-deploy) aplikasi. Saat server sedang kritis, alur ini membuang waktu berharga.
• Overhead Performa Tinggi: Profiler runtime bekerja dengan cara menginterupsi eksekusi program secara berkala atau menyuntikkan instrumentasi ke setiap panggilan fungsi. Hal ini memicu penurunan performa sebesar 10% hingga 30%, yang berisiko memperburuk kondisi server yang sudah megap-megap.
• Blind Spot pada Native Code: Profiler tingkat bahasa tidak dapat melihat aktivitas di luar runtime mereka, seperti panggilan sistem kernel Linux, alokasi memori C-library (glibc), atau pemrosesan driver jaringan.

Parca memecahkan tantangan ini dengan memanfaatkan eBPF (Extended Berkeley Packet Filter). eBPF memungkinkan program kecil berjalan langsung di dalam kernel Linux secara aman tanpa perlu mengubah kode sumber aplikasi atau memasang agent tambahan di dalam container.

Cara Kerja Parca eBPF dalam Mengambil Data Performance

Parca Agent beroperasi di kernel space Linux. Agent ini memasang probe pada timer interupsi kernel untuk melakukan inspeksi stack trace dari seluruh proses yang sedang berjalan di VPS, baik aplikasi Go, Node.js, Python, Rust, C++, maupun JVM.

Proses pengambilan data stack trace ini terjadi dengan overhead yang sangat minim (kurang dari 1% penggunaan CPU). Parca membaca tabel simbol executable (DWARF atau unwind tables) untuk menerjemahkan alamat memori di kernel menjadi nama fungsi dan baris kode yang mudah dibaca manusia. Data profil ini kemudian dikirimkan secara berkala ke Parca Server untuk disimpan dalam format kolom yang efisien (FrostDB) dan divisualisasikan dalam bentuk Flamegraph continuous.

Panduan Install Parca Server dan Parca Agent di VPS Linux

Mari kita praktikkan instalasi Parca pada server Linux VPS. Dalam tutorial ini, kita menggunakan Ubuntu 22.04 LTS dengan kernel Linux 5.15+. Pastikan VPS kamu memiliki fitur eBPF dan BTF (BPF Type Format) yang aktif.

Langkah 1: Verifikasi Dukungan Kernel Linux

Jalankan perintah berikut di terminal VPS untuk memastikan kernel mendukung eBPF dan BTF:

uname -r
ls -l /sys/kernel/btf/vmlinux

Jika file vmlinux tersedia, VPS kamu siap mengoperasikan Parca Agent tanpa perlu kompilasi ulang header kernel.

Langkah 2: Instalasi Parca Server via Docker

Cara termudah menjalankan Parca Server adalah menggunakan Docker Compose. Buat file bernama docker-compose.yaml pada directory server kamu:

version: '3.8'
services:
  parca-server:
    image: ghcr.io/parca-dev/parca:v0.20.0
    container_name: parca-server
    ports:
      - "7070:7070"
    command:
      - /parca
      - --config-file=/etc/parca/parca.yaml
    volumes:
      - ./parca.yaml:/etc/parca/parca.yaml:ro
    restart: always

Buat file konfigurasi minimal parca.yaml di direktori yang sama:

object_storage:
  bucket:
    type: "FILESYSTEM"
    config:
      directory: "./data"

scrape_configs:
  - job_name: "parca-agent"
    static_configs:
      - targets: ["host.docker.internal:7071"]

Jalankan Parca Server dengan perintah:

docker compose up -d

Langkah 3: Instalasi dan Konfigurasi Parca Agent (Native Binary)

Parca Agent wajib berjalan langsung di host VPS (bukan di dalam isolated container biasa) agar memiliki akses penuh ke kernel subsystem eBPF. Unduh binary resmi Parca Agent versi terbaru:

wget https://github.com/parca-dev/parca-agent/releases/download/v0.25.0/parca-agent_0.25.0_Linux_x86_64.tar.gz
tar -xvf parca-agent_0.25.0_Linux_x86_64.tar.gz
sudo mv parca-agent /usr/local/bin/

Buat systemd service unit agar Parca Agent berjalan otomatis saat VPS booting. Buat file /etc/systemd/system/parca-agent.service:

[Unit]
Description=Parca Agent eBPF Profiler
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/parca-agent \
  --remote-store-address=127.0.0.1:7070 \
  --remote-store-insecure=true \
  --log-level=info
Restart=always
RestartSec=5
LimitMEMLOCK=infinity

[Install]
WantedBy=multi-user.target

Aktifkan dan jalankan service Parca Agent:

sudo systemctl daemon-reload
sudo systemctl enable --now parca-agent
sudo systemctl status parca-agent

Periksa log service menggunakan journalctl -u parca-agent -f. Jika koneksi berhasil, agent akan mulai memindai PID aplikasi di VPS dan mengirimkan sampel data CPU ke Parca Server.

Analisis Flamegraph dan Troubleshooting Kebocoran Memori Backend

Buka browser kamu dan akses http://IP_VPS_KAMU:7070. Kamu akan disuguhkan antarmuka web Parca yang menampilkan data profil secara real-time maupun historis.

Membaca Grafis Flamegraph CPU

Di dashboard Parca, pilih metric process_cpu_samples dan tentukan rentang waktu saat server mengalami kelebihan beban. Parca akan menampilkan Flamegraph:

• Sumbu Horizontal (X): Menunjukkan proporsi waktu CPU yang dihabiskan. Semakin lebar kotak suatu fungsi, semakin banyak resource CPU yang dikonsumsi oleh fungsi tersebut beserta anak pemanggilnya.
• Sumbu Vertikal (Y): Menunjukkan urutan call stack. Bagian paling bawah adalah entry point (seperti main atau panggilan sistem kernel), sedangkan bagian atas adalah fungsi terujung yang sedang dieksekusi saat sampel diambil.

Sebagai contoh kasus, kita menemukan sebuah API backend Node.js yang mengalami penurunan response time. Saat melihat Flamegraph di Parca, terdapat balok lebar pada fungsi JSON.parse() dan regexpExec yang memakan 60% lebar grafik. Hal ini mengindikasikan bahwa aplikasi menghabiskan mayoritas waktu CPU bukan untuk I/O database, melainkan untuk proses serialisasi JSON berukuran besar dan parsing string regex yang tidak efisien.

Menemukan Kebocoran Memori (Memory Leak)

Selain profiler CPU, Parca eBPF dapat memantau alokasi memori melalui panggilan kernel seperti brk dan mmap. Untuk melacak memory leak pada service backend Go atau Rust di VPS:

1. Pilih metric alokasi memori pada dropdown query Parca.
2. Bandingkan dua rentang waktu yang berbeda menggunakan fitur Compare Mode (misalnya: data jam 10 pagi vs jam 2 siang).
3. Perhatikan balok warna merah pada diff Flamegraph. Balok merah menandakan adanya pertumbuhan alokasi memori yang tidak dilepaskan (freed) oleh Garbage Collector atau allocator sistem.

Melalui perbandingan ini, kamu dapat mengidentifikasi variabel global, slice yang terus bertambah, atau goroutine leak tanpa harus mengunduh file dump memori berukuran gigabyte yang berisiko membuat server Out of Memory (OOM).

Best Practices Penggunaan Parca di Environment Production

Agar implementasi continuous profiling berjalan optimal tanpa membebani storage VPS kamu, terapkan beberapa langkah berikut:

• Kelola Retention Policy Data: Data profil eBPF menghasilkan volume telemetry yang cepat membesar. Atur flag --retention-time pada Parca Server (misalnya 7 hari hingga 14 hari) untuk menghapus data lama secara otomatis.
• Simpan Debug Symbols: Agar Flamegraph dapat menampilkan nama fungsi dengan jelas (tidak hanya alamat memori mentah seperti 0x4012ab), pastikan binary aplikasi yang di-deploy di VPS tidak di-strip simbol debug-nya, atau upload file debuginfo ke server simbol internal.
• Batasi Akses Web UI: Dashboard Parca memperlihatkan struktur internal kode dan argumen proses. Lindungi port 7070 menggunakan reverse proxy (Nginx/Caddy) dengan otentikasi dasar atau letakkan di belakang VPN internal.

Kesimpulan

Continuous profiling berbasis eBPF mengubah cara kita mengatasi masalah performa di server Linux VPS. Dengan Parca, kamu tidak perlu lagi menebak-nebak baris kode mana yang membuat CPU spike atau menyuntikkan SDK tambahan yang memperlambat aplikasi. Langkah praktis yang bisa kamu lakukan sekarang: pasang Parca Agent di server staging kamu, amati bentuk Flamegraph aplikasi saat menerima beban stress test, dan temukan bottleneck CPU sebelum pengguna production kamu merasakannya.