Belajar Zabbix - Monitoring Infrastructure: Network, Cloud & Applications

#Pendahuluan

Selama dua belas episode, kalian memonitor host Linux. Episode 13 ini memperluas cakupan ke seluruh infrastruktur: perangkat network yang tidak bisa dipasangi agent, platform cloud yang abstraksi, aplikasi yang hanya berbicara HTTP, dan container yang datang dan pergi. Zabbix menangani semuanya lewat kombinasi protokol dan template.

Ini episode dengan cakupan terluas di fase ketiga. Tujuannya bukan menghafal semua template, melainkan memahami pola: bagaimana Zabbix berbicara dengan perangkat yang tidak punya agent, dan bagaimana template resmi memetakan platform eksternal ke dalam objek Zabbix.

#Monitoring Network dengan SNMP

#SNMP v1, v2c, dan v3

Perangkat network — switch, router, firewall — umumnya tidak bisa dipasangi agent Zabbix. Protokol standar yang dipakai adalah SNMP:

v1: versi lama, komunitas sebagai kredensial.
v2c: paling umum, efisien dan banyak didukung.
v3: dengan autentikasi dan enkripsi, direkomendasikan untuk produksi.

Item SNMP memakai OID, bukan key. OID seperti 1.3.6.1.2.1.1.3.0 mewakili uptime perangkat.

#Menguji Koneksi SNMP

Sebelum menambahkan host SNMP di Zabbix, uji akses dari server:

Walk OID dengan snmpwalk

snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.1

Perintah snmpwalk -v2c -c public 192.168.1.1 menampilkan semua variabel di OID tertentu. Jika snmpwalk berhasil, host SNMP siap ditambahkan ke Zabbix; jika tidak, masalah ada di kredensial, versi SNMP, atau reachability.

#ICMP Ping dan Kinerja Jaringan

Untuk ketersediaan dan kualitas jaringan, Zabbix menyediakan item ICMP: icmpping untuk status, icmppingloss untuk persentase paket hilang, dan icmppingsec untuk latensi. Item ini dikumpulkan oleh server tanpa agent sama sekali — cara termurah untuk memantau perangkat yang tidak mendukung SNMP. Nilai icmppingsec rata-rata bisa dijadikan trigger kualitas jaringan, misalnya ketika latensi melewati ambang tertentu.

#Monitoring Cloud dan Aplikasi

#Template Platform Cloud

Zabbix menyediakan template resmi untuk AWS, Azure, dan GCP. Template ini memakai integrasi API: Zabbix menarik metrik dari cloud provider dan mengonversinya menjadi item. Alih-alih memonitor instance satu per satu, kalian memonitor metrik terkelola seperti load balancer, database managed, dan autoscaling groups.

Biasanya kalian perlu menyediakan kredensial atau role dengan permission read-only di akun cloud, misalnya IAM role AWS atau service principal Azure. Konfigurasi lengkap bergantung provider, tapi pola umumnya sama: template mengambil metrik, preprocessing membersihkannya, dan trigger menilai ambang batas.

#Monitoring Aplikasi: HTTP, JMX, dan Database

Aplikasi modern dimonitor lewat beberapa jalur:

HTTP agent: meminta endpoint API dan memeriksa status code, waktu respons, atau meng-parsing JSON.
JMX: metrik Java melalui Zabbix Java gateway untuk aplikasi berbasis JVM.
Database monitoring: item tipe database mengeksekusi query SQL terhadap MySQL atau PostgreSQL.

Cek endpoint HTTP dari server

curl -s -o /dev/null -w "%{http_code}" https://app.example.com/health

Perintah curl -s -o /dev/null -w "%{http_code}" hanya menampilkan status code HTTP. Item HTTP agent di Zabbix melakukan hal yang sama secara berkala — dan dijadikan bahan trigger ketersediaan aplikasi.

Sedangkan aplikasi JVM memakai Zabbix Java gateway untuk mengambil metrik JMX. Pastikan gateway berjalan sebelum mengaktifkan item JMX:

Cek status Java gateway

systemctl status zabbix-java-gateway

Perintah systemctl status zabbix-java-gateway menampilkan status gateway. Tanpa gateway yang aktif, item JMX akan menampilkan error collection di Latest data.

#Container Monitoring

#Docker dan Kubernetes

Container menuntut discovery dinamis, dan di sinilah episode 11 tentang LLD bersinar. Template Docker by Zabbix agent 2 memakai plugin agent2 untuk mengambil metrik container: CPU, memory, network, dan status. Template Kubernetes memonitor cluster lewat node, pods, dan API server.

Objek yang dimonitor di Kubernetes

node → kubelet + metrik pods pada node
pod  → status dan resource usage
cluster → API server availability dan latency

Metrik Kubernetes membutuhkan layanan agent yang berjalan di dalam cluster. Detail deployment-nya bergantung versi Zabbix, tapi template resmi menyediakan instruksi lengkap dan item siap pakai. Perlu diingat bahwa metrik container diambil per namespace — Zabbix bisa membedakan resource yang dipakai container dari resource yang dipakai host secara terpisah.

Info

Mulailah dari satu lapisan: pantau perangkat network dengan SNMP dan satu aplikasi dengan HTTP agent terlebih dahulu. Setelah pola item dan trigger terasa nyaman, baru naik ke cloud dan Kubernetes yang cakupannya jauh lebih luas.

#Menyusun Strategi Multi-Lapisan

Infrastruktur nyata membutuhkan kombinasi semua jalur:

Agent untuk host yang bisa dipasangi agent.
SNMP dan ICMP untuk perangkat network.
HTTP, JMX, dan query database untuk aplikasi.
Template cloud untuk layanan terkelola.
LLD + template container untuk Docker dan Kubernetes.

Setiap jalur punya template resmi yang bisa dijadikan titik awal. Yang menentukan kualitas monitoring bukan banyaknya protokol yang dipakai, melainkan ketepatan memilih jalur untuk setiap lapisan.

#Penutup

Episode 13 memperluas cakupan monitoring: SNMP v1/v2c/v3 dan ICMP untuk network, template AWS/Azure/GCP untuk cloud, HTTP dan JMX untuk aplikasi, serta template Docker dan Kubernetes untuk container.

Inti yang harus dibawa pulang:

Perangkat network dimonitor dengan SNMP; uji dulu dengan snmpwalk.
ICMP ping adalah cara termurah memantau ketersediaan dan kualitas jaringan.
Template cloud memanfaatkan API provider untuk metrik terkelola.
HTTP agent, JMX, dan database monitoring menutupi lapisan aplikasi.
Container memakai LLD dan template Docker atau Kubernetes.

Di episode 14 selanjutnya kita akan membahas Zabbix API dan automation — protokol JSON-RPC, autentikasi dengan API token, operasi host, item, trigger, dan alert lewat API, serta automation dengan zabbix-cli, Terraform, dan Python pyzabbix.