Belajar Redis - Monitoring & Observability (Prometheus & Grafana)

#Pendahuluan

Redis bisa saja berjalan mulus hari ini — tapi produksi menuntut bukti, bukan harapan. Episode 18 ini membahas monitoring dan observability: bagaimana memeriksa kesehatan Redis secara real-time, mengekspor metriknya ke sistem monitoring modern, dan memicu alert sebelum masalah menjadi insiden.

Kalian akan belajar tiga lapisan: membaca INFO langsung dari Redis, menjembatani metrik ke Prometheus dengan redis_exporter, lalu memvisualisasikan dan meng-alert di Grafana. Di akhir episode, kalian punya template dashboard yang siap dipakai di produksi.

#Memantau Kesehatan dengan INFO

#Enam Seksi Kunci

INFO adalah pintu masuk observability. Perintah ini bisa dipersempit per seksi:

redis-cli INFO clients
redis-cli INFO stats
redis-cli INFO memory
redis-cli INFO replication

INFO clients menampilkan koneksi aktif (connected_clients) dan yang diblokir. INFO stats memberi total_commands_processed, keyspace_hits, dan keyspace_misses. INFO memory memakai used_memory dan maxmemory. INFO replication menampilkan master_link_status dan lag replica. Kombinasi keempat seksi ini menjawab 80% pertanyaan kesehatan Redis.

#Hit Ratio

Salah satu metrik paling berharga: cache hit ratio. Dihitung dari dua counter:

hit_ratio = keyspace_hits / (keyspace_hits + keyspace_misses)

Nilai di atas 0.95 umumnya sehat; turun drastis berarti cache jarang kepakai — TTL terlalu pendek, atau workload tidak cocok dengan pola cache. Metrik inilah yang biasanya ditaruh paling atas dashboard.

#MONITOR: Hati-Hati

MONITOR menampilkan semua perintah yang lewat secara live — sangat berguna untuk debugging, tapi berbahaya di produksi:

redis-cli MONITOR

redis-cli MONITOR mencetak setiap perintah real-time. Masalahnya: MONITOR menambah overhead besar di server traffic tinggi, dan bisa menjadi kebocoran informasi sensitif. Aturan main: hanya untuk debugging singkat, tidak pernah dibiarkan menyala di produksi — biasanya di-nonaktifkan lewat ACL.

#Ekosistem Prometheus

#Menjalankan redis_exporter

Redis tidak mengekspor metrik dalam format Prometheus — redis_exporter (project oliver006/redis_exporter) menjembatani keduanya. Jalankan sebagai sidecar atau service:

docker run -d --name redis-exporter \
  -p 9121:9121 \
  -e REDIS_ADDR=redis://127.0.0.1:6379 \
  oliver006/redis_exporter:latest

docker run ... oliver006/redis_exporter membuat exporter mendengarkan di port 9121 dan menarik metrik dari Redis di REDIS_ADDR. Endpoint http://localhost:9121/metrics sekarang menyajikan semua metrik dalam format Prometheus.

#Konfigurasi Scrape di Prometheus

Beri tahu Prometheus endpoint mana yang di-scrape:

scrape_configs:
  - job_name: redis
    static_configs:
      - targets: ["redis-exporter:9121"]

targets: ["redis-exporter:9121"] mendaftarkan exporter. Prometheus akan mengambil metrik berkala dan menyimpannya untuk query. Untuk Redis Cluster, daftarkan semua node atau pakai --redis-only-master untuk metrik ringkas.

#Metrik Penting yang Harus Diamati

#Kandidat Utama

Beberapa metrik yang paling sering menjadi alarm:

• redis_connected_clients: lonjakan tak wajar bisa menandakan connection leak.
• redis_memory_used_bytes vs redis_memory_max_bytes: mendekati batas = segera eviction.
• redis_evicted_keys_total: naik terus = maxmemory terlalu rendah.
• redis_keyspace_hits_total / redis_keyspace_misses_total: basis hit ratio.
• redis_connected_slaves dan redis_master_last_io_seconds_ago: health replication.
• redis_slowlog_length: banyaknya perintah lambat yang terantre.

#Dashboard Grafana

Di Grafana, impor dashboard resmi komunitas (misal ID 763) yang sudah menyusun semua metrik di atas menjadi panel: memori, client, hit ratio, eviction, dan replication. Alurnya:

redis ──> redis_exporter :9121 ──> prometheus ──> grafana (query + alert)

Kalian tinggal menambahkan data source Prometheus di Grafana dan memilih dashboard. Untuk prod, custom dashboard dengan panel hit ratio dan eviction biasanya paling sering dipandang.

#Alerting

#Aturan Alert yang Masuk Akal

Data di dashboard tidak ada gunanya tanpa alert yang tepat waktu. Contoh aturan yang umum dipakai:

groups:
  - name: redis.rules
    rules:
      - alert: RedisMemoryHigh
        expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.85
        for: 10m
        labels:
          severity: warning

expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.85 memicu alert RedisMemoryHigh saat pemakaian memori di atas 85% selama 10 menit. Beberapa aturan lain yang direkomendasikan:

• Hit ratio rendah: keyspace_hits / (hits + misses) < 0.5 selama 30 menit.
• Replication lag tinggi: master_last_io_seconds_ago > 60.
• Eviction tinggi: rate(redis_evicted_keys_total[5m]) > 0 secara konsisten.
• Server down: up{job="redis"} == 0.

#Penutup

Episode 18 membekali kalian observability end-to-end: membaca seksi INFO, memahami risiko MONITOR, mengekspor metrik via redis_exporter ke Prometheus, memvisualisasikan di Grafana, dan menyusun alerting untuk memori, hit ratio, dan replication lag.

Inti yang harus dibawa pulang:

• INFO clients, INFO stats, INFO memory, INFO replication menjawab 80% kesehatan Redis.
• Hit ratio = keyspace_hits / (hits + misses); di bawah 0.5 adalah sinyal masalah.
• MONITOR hanya untuk debugging singkat — berbahaya dan di-disable di produksi.
• redis_exporter di port 9121 menjembatani Redis ke Prometheus.
• Awasi connected_clients, memori vs maxmemory, evicted_keys, dan replication lag.
• Grafana dashboard resmi (ID 763) menyiapkan visualisasi siap pakai.
• Alert harus spesifik dan actionable, misal memori > 85% selama 10 menit.

Di episode 19 selanjutnya kita membahas Troubleshooting & Operational Maintenance — menghadapi masalah nyata. Kalian akan belajar menangani high latency spikes, error OOM, connection exhaustion, replication disconnect, menjadwalkan BGSAVE/BGREWRITEAOF, rolling upgrade, serta prosedur disaster recovery. Siap siaga?