Belajar Zabbix - Performance Tuning & Capacity Planning

#Pendahuluan

Zabbix yang sehat hari ini belum tentu sehat saat jumlah host bertambah tiga kali lipat. Episode 17 ini membahas dua disiplin yang membuat Zabbix tetap kuat seiring pertumbuhan: performance tuning untuk memaksimalkan kapasitas yang ada, dan capacity planning untuk memperkirakan kebutuhan sebelum terjadi.

Keduanya bekerja bersama. Tuning mengoptimalkan parameter tanpa menambah hardware; capacity planning memberitahu kapan tuning tidak lagi cukup dan hardware harus ditambah. Di episode ini kalian juga belajar memonitor Zabbix menggunakan Zabbix — praktik yang memastikan server monitoring tidak menjadi titik buta terakhir di infrastruktur.

#Parameter Kinerja Utama

#Cache di zabbix_server.conf

Zabbix server menyimpan data di berbagai cache di dalam memori. Ukuran cache menentukan berapa banyak data yang bisa ditangani sebelum tertulis ke database:

• CacheSize: cache konfigurasi — host, item, dan trigger.
• HistoryCacheSize: buffer history yang menunggu ditulis ke database.
• TrendCacheSize: buffer data trend.
• ValueCacheSize: cache nilai item untuk mempercepat query.

CacheSize=128M
HistoryCacheSize=64M
ValueCacheSize=64M

Ukuran yang tepat bergantung volume data. Pantau penggunaan cache melalui internal checks — jika cache hampir penuh secara konsisten, naikkan angkanya.

#Jumlah Worker

Jumlah proses worker menentukan paralelisme collection. Parameter yang paling sering disesuaikan:

• StartPollers: worker untuk passive check dan SNMP.
• StartTrappers: worker yang menerima data dari agent aktif dan proxy.
• StartPollersUnreachable: worker khusus untuk host yang tidak terjangkau.

zabbix_server --config /etc/zabbix/zabbix_server.conf | grep -i start

Perintah zabbix_server --config ... | grep -i start menampilkan nilai parameter worker saat ini. Aturan sederhana: tambah worker sampai tidak ada antrean data — ditandai metrik queue mendekati nol — lalu berhenti.

#Database Tuning

Database adalah bottleneck paling umum pada Zabbix besar. Beberapa penyesuaian yang sering memberikan dampak besar:

• Pastikan tabel history dan trends berada di disk yang cukup cepat (SSD).
• Sesuaikan buffer pool MySQL (innodb_buffer_pool_size) atau shared_buffers PostgreSQL agar porsi besar database berada di memori.
• Pertimbangkan TimescaleDB dari episode 12 untuk partisi otomatis.

MySQL: innodb_buffer_pool_size ~ 70% dari RAM yang dialokasikan
PostgreSQL: shared_buffers ~ 25% dari RAM yang dialokasikan

Angka di atas adalah titik mulai, bukan rumus final. Ukur performa nyata dan sesuaikan berdasarkan observasi, bukan asumsi.

#Capacity Planning

#Formula NVP

NVP (new values per second) adalah metrik paling penting untuk sizing Zabbix — jumlah nilai baru yang masuk per detik. Rumusnya sederhana:

NVP = (jumlah item yang dikumpulkan) / (interval rata-rata dalam detik)

Contoh: 6000 item dengan interval rata-rata 60 detik menghasilkan 100 NVP. Jika setengahnya memakai active check, NVP efektif turun — agent aktif lebih efisien karena server tidak menunggu koneksi.

#Sizing untuk 1K, 10K, dan 50K Host

Panduan hardware resmi Zabbix memberikan perkiraan per tingkatan NVP:

10 ribu NVP   → 2 vCPU, 4 GB RAM
30 ribu NVP   → 4 vCPU, 8 GB RAM
70 ribu NVP   → 8 vCPU, 16 GB RAM
160 ribu NVP  → 16 vCPU, 32 GB RAM

Untuk 1000 host dengan rata-rata 500 item per host dan interval 60 detik, NVP sekitar 8000 — masih nyaman di tingkatan pertama. 10 ribu host melonjak ke puluhan ribu NVP dan butuh beberapa server atau proxy yang terdistribusi.

#Memonitor Zabbix Itu Sendiri

#Internal Checks dan Queue

Zabbix menyediakan item internal untuk memonitor dirinya sendiri: zabbix[queue] menunjukkan data yang belum diproses, zabbix[history] dan zabbix[trends] mengukur kecepatan tulis database, dan zabbix[process,<type>] memantau worker.

zabbix[queue]                 → antrean data yang menunggu diproses
zabbix[process,history]       → kecepatan tulis history per detik
zabbix[stats,127.0.0.1,10051] → statistik server secara keseluruhan

Metrik zabbix[stats,127.0.0.1,10051] memberikan gambaran kesehatan server dalam satu item. Gabungkan item internal dengan template "Zabbix Server" resmi — template ini sudah berisi item dan trigger untuk memonitor server itu sendiri.

#Langkah-Langkah Sebelum Menambah Hardware

Urutan yang disarankan saat performa menurun:

• Pantau queue dan cache utilization untuk menemukan bottleneck.
• Sesuaikan cache dan jumlah worker terlebih dahulu.
• Tune database dan pertimbangkan partisi.
• Tambah hardware atau node hanya setelah tuning tidak mencukupi.

#Penutup

Episode 17 membuat Zabbix siap tumbuh: cache dan worker disesuaikan lewat zabbix_server.conf, database di-tuning untuk menghindari bottleneck, NVP menjadi dasar capacity planning, dan internal checks menjaga Zabbix tetap bisa memonitor dirinya sendiri.

Inti yang harus dibawa pulang:

• Cache menyangga data di memori; ukurannya menyesuaikan volume data.
• StartPollers dan StartTrappers menentukan paralelisme collection.
• NVP = nilai baru per detik, dasar perhitungan sizing.
• Database adalah bottleneck utama; alokasikan buffer pool sesuai RAM.
• Pasang template Zabbix Server agar Zabbix memonitor dirinya sendiri.

Di episode 18 selanjutnya kita akan membahas advanced templates dan integrations — integrasi webhook resmi seperti PagerDuty, Slack, dan Jira, push data ke Prometheus, custom plugin agent2, dan ekspor-impor template YAML.