Monitoring Server dengan Zabbix: Panduan Implementasi Praktis

Memasang Zabbix biasanya tidak sulit. Zabbix server, database, web frontend, dan template resminya bisa disiapkan dalam satu atau dua hari, dan network discovery membantu menambahkan host secara otomatis. Masalahnya datang beberapa minggu kemudian: grup notifikasi penuh alert yang tidak penting, tim mulai mengabaikannya, dan saat ada insiden sungguhan, alert-nya tenggelam. Di atas kertas semua server terpantau, tapi dalam praktiknya tidak ada yang memperhatikan.

Kenapa Zabbix Sering Jadi Terlalu Berisik

Template resmi Zabbix dibuat supaya bisa dipakai di banyak jenis lingkungan, jadi isinya banyak pengecekan dengan threshold bawaan. Di server Anda, template ini bisa memicu alert untuk CPU yang naik saat batch job berjalan, memori yang terlihat penuh padahal dipakai sebagai cache, atau timeout jaringan sesaat yang pulih sendiri. Kondisi seperti ini tidak butuh tindakan, tapi setiap notifikasinya tetap menyita perhatian orang.

Lama-lama efeknya makin terasa. Kalau sebagian besar notifikasi cuma informasi, tim harus menilai setiap alert satu per satu sebelum tahu mana yang penting, dan respons ke insiden sungguhan jadi lambat. Jadi urusan mengurangi alert yang tidak perlu harus dikerjakan sejak awal implementasi, jangan ditunda sampai tim sudah terbiasa mengabaikan notifikasi.

Rancang Arsitektur Dulu Sebelum Menambah Host

Zabbix terdiri dari server yang mengevaluasi trigger dan menjalankan action, database untuk konfigurasi dan metrik, web frontend, dan agent atau protokol lain untuk mengumpulkan data. Hitung kapasitasnya dari jumlah nilai baru per detik (new values per second). Jumlah host saja tidak cukup jadi patokan, karena satu server dengan low-level discovery untuk empat puluh filesystem dan dua puluh network interface bisa lebih berat daripada sepuluh host sederhana. Untuk instalasi besar, PostgreSQL dengan TimescaleDB jadi pilihan umum karena partisi dan kompresi data time-series-nya lebih efisien.

Putuskan pemakaian Zabbix proxy sejak awal, sebelum host-nya terlanjur banyak. Proxy mengumpulkan data atas nama server untuk kantor cabang, DMZ, atau jaringan pelanggan. Proxy juga menyimpan data sementara saat koneksi putus, lalu mengirimnya lewat satu koneksi keluar, jadi server tidak perlu menjangkau setiap host langsung. Untuk lingkungan yang tersebar di beberapa jaringan atau data center, satu proxy per lokasi adalah titik awal yang wajar.

Ukuran database lebih banyak dipengaruhi oleh pengaturan retensi daripada jumlah host. History menyimpan data mentah, berguna untuk melihat apa yang terjadi di menit tertentu tadi malam. Trend menyimpan ringkasan per jam untuk analisis kapasitas berbulan-bulan, dengan ukuran data jauh lebih kecil. Tentukan retensi keduanya sejak desain, supaya tidak ada cerita housekeeping baru diatur buru-buru karena disk database sudah penuh.

Apa yang Dipantau di Setiap Layer

Mulailah dari hal yang dirasakan pengguna, baru kemudian resource di bawahnya. Server dengan CPU 95 persen yang masih melayani request sesuai target latency belum tentu masalah. Server dengan CPU 40 persen yang berhenti menerima koneksi jelas masalah, dan hanya kondisi kedua yang perlu mengganggu tim.

Uji sederhana untuk setiap trigger: kalau alert ini masuk jam tiga pagi, apa yang harus dilakukan penerimanya? Kalau jawabannya "tidak ada", turunkan severity-nya atau hapus trigger-nya.

Desain Trigger dan Severity yang Bisa Ditindaklanjuti

Zabbix punya enam tingkat severity, dan tingkatan itu baru berguna kalau masing-masing punya arti yang jelas. Contoh pembagian yang praktis: Warning dicek di jam kerja, High harus ditangani di shift yang sedang berjalan, dan Disaster boleh membangunkan orang. Severity ini kemudian menentukan ke mana notifikasi dikirim. Tingkat rendah cukup masuk grup chat, tingkat tertinggi langsung ke tim on-call.

• Nilai kondisi dalam rentang waktu, jangan dari satu pembacaan. Fungsi seperti avg(/host/key,10m) jauh lebih stabil daripada last(/host/key) yang bereaksi pada setiap lonjakan.
• Tambahkan recovery expression supaya metrik yang naik turun di sekitar threshold tidak terus-menerus memicu problem lalu resolve.
• Pakai trigger dependency supaya host yang tidak terjangkau tidak sekaligus memunculkan alert untuk setiap service di dalamnya.
• Jadwalkan maintenance period untuk pekerjaan terencana, supaya downtime yang sudah diketahui tidak memanggil tim on-call.
• Pasang tag secara konsisten untuk environment, service, dan pemilik sistem. Tag inilah yang dipakai untuk action condition dan event correlation saat instalasinya makin besar.
• Tulis tindakan yang diharapkan di deskripsi trigger atau tautkan ke runbook, supaya orang yang menerima alert jam tiga pagi tidak perlu mencari konteksnya dari nol.

Cara Zabbix Mengumpulkan Data

Zabbix agent mendukung dua mode. Di passive check, server yang menghubungi agent di port 10050. Di active check, agent yang menghubungi server di port 10051 lalu mengambil daftar item yang harus dikumpulkan. Active check biasanya lebih cocok untuk lingkungan dengan NAT, firewall yang ketat, atau host yang sangat banyak, karena koneksinya keluar dari host dan beban polling di server berkurang.

Tidak semua perangkat bisa dipasangi agent. Perangkat jaringan biasanya dipantau lewat SNMP, ketersediaan dasar lewat ICMP dan pengecekan TCP, endpoint web lewat item HTTP agent, dan aplikasi Java lewat Zabbix Java gateway dengan item JMX. Zabbix agent 2 juga punya plugin untuk layanan umum seperti PostgreSQL, MySQL, Redis, dan Docker, jadi banyak kebutuhan standar tidak perlu script tambahan.

Low-level discovery membuat item otomatis untuk hal yang berulang seperti filesystem dan network interface, sehingga konfigurasi tetap akurat walaupun server berubah. Desain template ternyata sangat menentukan. Tautkan template ke host group dan simpan hasil ekspornya di Git kalau memungkinkan. Konfigurasi manual per host sulit dirawat saat jumlahnya banyak, dan biasanya jadi penyebab dua server yang sama ternyata dipantau dengan cara berbeda.

Kekuatan Zabbix dan Bagian yang Perlu Tool Lain

Zabbix kuat untuk memantau infrastruktur dan ketersediaan. Pengumpulan dan penyimpanan metriknya andal, bisa menangani banyak jenis perangkat dari switch sampai virtual machine dan container, dan fitur eskalasinya lebih lengkap dari yang biasanya dipakai tim. Tapi batasannya perlu dipahami dari awal. Kalau berharap Zabbix bisa menjelaskan kenapa aplikasi lambat, tim akan kecewa di insiden performa pertama.

• Untuk tahu query atau fungsi mana yang membuat sebuah request lambat, tim butuh APM tool. Zabbix hanya bisa melaporkan bahwa response time naik.
• Distributed tracing antar microservice ada di luar cakupan Zabbix.
• Pencarian dan korelasi log dalam jumlah besar lebih cocok ditangani platform log khusus, walaupun Zabbix bisa memantau file log untuk pola tertentu dan memicu alert dari situ.
• Dashboard untuk manajemen atau tim lain sering dibuat di Grafana dengan Zabbix sebagai sumber data, sementara pengumpulan data dan alert tetap di Zabbix.

Urutan Implementasi Zabbix

1. 1Buat daftar layanan dulu sebelum konfigurasi teknis: sistem apa saja yang ada, siapa pemiliknya, dan apa dampaknya kalau masing-masing mati. Alert yang tidak punya pemilik tidak akan diurus siapa pun.
2. 2Mulai dari sedikit host yang mewakili berbagai jenis server. Sepuluh host yang dikonfigurasi dengan teliti mengajarkan lebih banyak soal perilaku threshold daripada empat ratus host dengan template default.
3. 3Sesuaikan template dengan trafik sebenarnya selama minimal satu siklus bisnis penuh, termasuk tutup buku akhir bulan kalau relevan, sebelum notifikasi dinyalakan untuk semua host.
4. 4Pisahkan tujuan notifikasi berdasarkan severity. Warning cukup ke grup chat, High dan Disaster ke tim on-call. Mengirim semua severity ke satu tempat adalah penyebab paling umum alert diabaikan.
5. 5Tambahkan proxy setiap kali ada lokasi baru, dan tentukan retensi history dan trend di waktu yang sama. Tulis keputusannya, jangan dibiarkan memakai nilai default sampai disk penuh.
6. 6Tinjau trigger setiap bulan selama tiga bulan pertama. Untuk setiap alert yang muncul tapi tidak butuh tindakan, pilih salah satu: perpanjang rentang evaluasinya, ubah threshold-nya, atau hapus.

Tanda Monitoring Zabbix Sudah Berjalan Baik

• Jumlah notifikasi per minggu masih bisa ditangani, dan sebagian besar memang butuh tindakan.
• Setiap alert punya pemilik dan langkah penanganan yang jelas.
• Rencana kapasitas memakai data trend, tidak berdasarkan perkiraan.
• Disk yang hampir penuh ketahuan beberapa hari sebelumnya.
• Data history cukup untuk menyusun kronologi saat evaluasi setelah insiden.