Belajar Zabbix - Data Management: History, Trends & Housekeeper

#Pendahuluan

Sampai episode 11, kalian fokus mengumpulkan data. Episode 12 ini membahas pertanyaan yang mulai muncul saat data menumpuk: di mana semua angka ini disimpan, berapa lama, dan bagaimana agar database tidak meledak. Ini adalah pelajaran tentang data management — sisi Zabbix yang paling sering diremehkan sampai infrastruktur tumbuh.

Dua konsep menjadi pusat episode ini: history sebagai data mentah dan trends sebagai agregasi. Setelah memahami keduanya, kalian akan belajar mengatur retention, memakai housekeeper, dan menggunakan TimescaleDB untuk deployment dengan volume data besar.

#History: Data Mentah

#Apa yang Disimpan di History

History menyimpan setiap nilai yang dikumpulkan item. Jika sebuah item dikumpulkan tiap menit, ada 1440 baris history per hari. Data ini adalah sumber dari grafik dengan resolusi penuh dan evaluasi trigger menggunakan fungsi seperti last() dan avg().

Karena sifatnya granular, history memakan ruang paling besar di database. Retention history default Zabbix adalah 90 hari untuk data teks, sementara data numerik biasanya dibatasi lebih pendek.

#Menentukan Retention History

Retention diatur di form item atau template, pada parameter History. Pertanyaan yang membantu menentukan angkanya: berapa lama kalian benar-benar butuh data mentah? Jawaban yang umum adalah 7-31 hari; di luar itu, agregasi trends sudah cukup untuk hampir semua kebutuhan analisis. Untuk item bertipe text dan log, pertimbangkan retention yang lebih pendek — data log biasanya hanya berguna untuk debugging jangka pendek, dan ukurannya membengkak jauh lebih cepat daripada angka.

#Trends: Agregasi Per Jam

#Mengapa Trends Ada

Trends menyimpan agregasi per jam dari nilai item: minimum, maksimum, rata-rata, dan jumlah nilai dalam jam tersebut. Satu item hanya menghasilkan 24 baris trends per hari, dibanding 1440 baris history. Inilah jawaban Zabbix untuk menyimpan tren jangka panjang tanpa memakan ruang.

Graph di Zabbix menggabungkan keduanya secara transparan: rentang waktu pendek ditampilkan dari history, rentang panjang dari trends. Operator tidak perlu memikirkan mana yang dipakai — tapi memahami ini penting untuk keputusan retention. Saat merencanakan penyimpanan, ingat bahwa retention trends biasanya dibuat jauh lebih panjang daripada history, sehingga grafik jangka panjang tetap tersedia tanpa menyimpan data mentah yang mahal.

mysql -uzabbix -p zabbix -e "SHOW TABLE STATUS LIKE 'history';"
mysql -uzabbix -p zabbix -e "SHOW TABLE STATUS LIKE 'trends';"

Perintah SHOW TABLE STATUS LIKE 'history' menampilkan ukuran tabel history di MySQL. Membandingkan ukuran kedua tabel adalah cara cepat meyakinkan diri sendiri mengapa trends wajib ada.

#Retention dan Housekeeper

#Mengatur Retention di Template

Kebijakan terbaik menempatkan retention di template, bukan di tiap host. Dengan begitu, satu perubahan diterapkan ke semua host yang menautkan template. Aturan praktis yang banyak dipakai: history numerik 7-31 hari, trends 365 hari, dan text lebih pendek dari angka.

#Peran Housekeeper

Housekeeper adalah proses server yang menghapus data yang lewat retention secara berkala. Tanpa housekeeper, database tumbuh tanpa henti dan hard disk cepat penuh. Housekeeper berjalan di dalam server; statusnya bisa dilihat lewat item internal zabbix[process,housekeeper].

zabbix_get -s 127.0.0.1 -k zabbix[process,housekeeper]

Perintah zabbix_get -s 127.0.0.1 -k zabbix[process,housekeeper] menampilkan berapa banyak record yang telah dihapus housekeeper. Jika nilainya nol terus-menerus padahal data sudah lewat retention, periksa apakah proses housekeeper berjalan dan pengaturan retention sudah benar.

#TimescaleDB untuk Skala Besar

#Masalah dengan Tabel Raksasa

Pada skala besar, operasi delete housekeeper terhadap tabel raksasa menjadi mahal. Solusi umum adalah partisi — memecah tabel per hari atau per bulan. Zabbix dengan PostgreSQL menawarkan integrasi TimescaleDB, yang mengelola partisi sebagai hypertables secara otomatis. Partisi juga membantu menjaga fragmentasi index tetap rendah, karena setiap chunk berukuran kecil dan terisolasi satu sama lain.

#Hypertables dan Manajemen Otomatis

TimescaleDB membagi hypertable menjadi chunks per interval waktu. Delete data lama menjadi operasi drop chunk yang sangat cepat, dan query dengan filter waktu memakai chunk yang relevan saja. Keuntungan kedua adalah penulisan paralel: data baru masuk ke chunk yang aktif tanpa mengganggu chunk historis.

history → chunks per 1 hari → drop chunk saat lewat retention
trends  → chunks per 1 bulan → drop chunk saat lewat retention

Zabbix menyediakan skrip timescaledb.sql untuk mengonversi schema database PostgreSQL standar menjadi hypertables. Konversi dilakukan sekali dan hasilnya permanen — nilai yang sudah ada tetap bisa dipakai.

apt install -y postgresql-16-timescaledb
timescaledb-tune --conf-path /etc/postgresql/16/main/postgresql.conf

Paket timescaledb-tune menyesuaikan parameter PostgreSQL untuk beban TimescaleDB secara otomatis. Setelah ekstensi aktif di database Zabbix, jalankan skrip konversi schema yang disediakan Zabbix sesuai urutan yang ada di dokumentasi resmi.

#Kapan Pindah ke TimescaleDB

Pindah ke TimescaleDB masuk akal ketika database mulai menunjukkan gejala: housekeeper memakan waktu lama, query history lambat, atau rencana pertumbuhan data jelas besar. Untuk lingkungan dengan ratusan host dan interval pendek, partisi TimescaleDB sering kali menjadi pembeda antara database yang sehat dan yang menyeret seluruh sistem.

#Merencanakan Kebijakan Penyimpanan

Rangkuman alur pengambilan keputusan:

• Tentukan kebutuhan analisis: berapa lama data mentah benar-benar dipakai.
• Set retention di template sesuai kebutuhan, bukan di host individual.
• Pantau ukuran tabel history dan trends secara berkala.
• Pertimbangkan TimescaleDB saat pertumbuhan data mulai memperlambat sistem.

Keputusan retention yang baik menyeimbangkan kebutuhan operasional dengan biaya penyimpanan. Data yang terlalu lama disimpan hanya membuang ruang; data yang terlalu cepat dihapus akan merugikan saat audit atau analisis tren.

#Penutup

Episode 12 menjelaskan arsitektur penyimpanan Zabbix: history menyimpan data mentah granular, trends meringkasnya menjadi agregasi per jam, housekeeper menjaga database tetap ramping, dan TimescaleDB menangani skala besar dengan hypertables.

Inti yang harus dibawa pulang:

• History adalah data mentah; trends adalah agregasi per jam yang ringkas.
• Retention diatur di template, biasanya 7-31 hari untuk history dan 365 hari untuk trends.
• Housekeeper menghapus data lewat retention secara berkala.
• TimescaleDB mengubah history dan trends menjadi hypertables berchunks.
• Backup lengkap wajib dilakukan sebelum konversi ke TimescaleDB.

Di episode 13 selanjutnya kita akan membahas monitoring infrastructure: network, cloud, dan applications — monitoring perangkat network dengan SNMP v1/v2c/v3, ICMP ping, template cloud AWS/Azure/GCP, HTTP dan JMX untuk aplikasi, serta integrasi container Docker dan Kubernetes.