Belajar Zabbix - Observability: Log Monitoring & Business Metrics

#Pendahuluan

Metrik menjawab "berapa?" — log menjawab "kenapa?". Episode 19 ini membuka dimensi observability yang belum tersentuh di episode-episode sebelumnya: log monitoring untuk memahami apa yang sebenarnya terjadi di dalam sistem, dan business service untuk menerjemahkan kesehatan teknis menjadi dampak bisnis.

Dua topik ini melengkapi gambaran. Log monitoring memberi sinyal yang tidak bisa diberikan metrik — pola error, serangan, dan perilaku aneh. Business service, di sisi lain, menaikkan sudut pandang dari item individual ke layanan end-to-end yang benar-benar dinilai oleh pelanggan.

#Log Monitoring

#Item Log dan Logrt

Zabbix memonitor file log lewat item tipe Zabbix agent dengan key log[] dan logrt[]. Keduanya membaca baris baru dari file log:

• log[]: memonitor satu file log dengan nama tetap.
• logrt[]: memonitor file log yang namanya berubah — pola yang umum untuk log bergilir harian seperti access.log yang menjadi access.log.2026-08-10.

log[/var/log/nginx/error.log, "error", "utf8"]
logrt[/var/log/nginx/access.log, "500|502", "utf8", 1]

Item log menghasilkan nilai untuk setiap baris yang cocok dengan pattern, lengkap dengan file, timestamp, dan source — detail lengkapnya bisa dibaca di dokumentasi resmi Zabbix.

#Parsing Log dengan Item

Untuk contoh nyata, item berikut memantau error Nginx:

tail -n 20 /var/log/nginx/error.log | grep "error"

Perintah tail -n 20 ... | grep "error" menampilkan 20 baris terakhir yang mengandung kata error. Item log Zabbix melakukan hal serupa secara real-time — setiap baris yang cocok pattern menjadi satu nilai yang bisa memicu trigger.

#Analisis Log ala Fail2ban

Pola klasik log monitoring adalah mendeteksi percobaan login gagal berulang. Dengan logrt[] pada log autentikasi dan trigger count():

count: jumlah baris "Failed password" dalam 10 menit
ambang: lebih dari 5 percobaan

Jika jumlahnya melampaui ambang, Zabbix mengirim alert — perilaku yang meniru fail2ban tapi dengan notifikasi penuh Zabbix: media, escalation, dan action log. Gabungkan dengan remote command dari episode 8 untuk mengambil tindakan otomatis.

#Business Services (BSM)

#Service Tree dan SLI/SLO

Business service monitoring memetakan layanan bisnis ke komponen teknis di bawahnya. Contoh sederhana: layanan "Website E-commerce" bergantung pada database, aplikasi, dan load balancer.

Website E-commerce (SLI/SLO)
    ├── Web server (10)
    ├── Application (10)
    └── Database (10)

Setiap layanan memiliki SLI (indikator yang diukur, misalnya availability) dan SLO (target, misalnya 99.9%). Zabbix menghitung kesehatan layanan dari kesehatan komponennya dan menampilkannya sebagai status problem atau OK.

#Weighted Service Metrics

Tidak semua komponen sama pentingnya. Zabbix memungkinkan bobot berbeda per layanan — database yang gagal lebih berdampak daripada cache yang gagal:

Website E-commerce
    ├── Web server (30)
    ├── Application (40)
    └── Database (30)

Bobot dan prioritas menentukan seberapa cepat kesehatan layanan turun saat satu komponen bermasalah. Dengan perhitungan berbobot, satu nilai kesehatan per layanan bisa dijadikan dasar laporan dan dashboard eksekutif.

#Service-Level Reporting

Karena kesehatan layanan tersimpan sebagai nilai berkala, Zabbix bisa menghitung persentase waktu layanan dalam keadaan OK — dasar perhitungan availability yang mendekati SLI nyata:

SLO target:     99.9%  (52,6 menit downtime diizinkan per bulan)
Aktual bulan ini: 99.94%

Perbandingan antara target dan aktual inilah yang dibawa ke meeting bisnis. Data monitoring akhirnya berbicara dalam bahasa yang sama dengan kontrak layanan.

#Menghubungkan Log dengan Business Service

Log dan business service saling menguatkan. Log memberikan konteks "kenapa" ketika business service menunjukkan "berapa turun". Saat layanan Website E-commerce berubah merah, operator tidak perlu menebak — log di komponen terkait sudah menunjukkan pola error yang mendasarinya.

Praktik terbaiknya: tautkan item log yang paling diagnostik ke service tree, sehingga investigasi dari layanan bermasalah langsung menunjuk ke log yang relevan.

#Penutup

Episode 19 melengkapi observability: item log dan logrt untuk parsing log real-time, pola analisis ala fail2ban untuk keamanan, serta business service dengan service tree, SLI/SLO, dan weighted metrics untuk berbicara dalam bahasa bisnis.

Inti yang harus dibawa pulang:

• Item log memantau file log dengan pattern dan menghasilkan nilai per baris.
• log[] untuk file tetap; logrt[] untuk log yang berganti nama.
• Pola fail2ban memakai count() atas baris login gagal berulang.
• Service tree memetakan layanan bisnis ke komponen teknis.
• Weighted metrics dan SLI/SLO mengubah monitoring menjadi bahasa bisnis.

Di episode 20 selanjutnya kita akan membahas OpenTelemetry dan Zabbix 8.0 — integrasi OTel collector dan ingestion metrics, logs, dan traces, fitur Zabbix 8.0 LTS, serta jalur migrasi dari 7.0 LTS.