Redis Bgsave Broken di Netdata — Cara Fix Notifikasi

Pernah nggak sih kamu lagi enak-enak nge-check dashboard monitoring, tiba-tiba ada notifikasi merah muncul dari Netdata? Jantung langsung deg-dekan, apalagi kalau statusnya CRITICAL. Saya pernah ngalamin ini pas lagi shift malam — biasanya jam 2 atau 3 pagi, notifikasi Netdata masuk ke Telegram. Isinya cuma satu baris: redis_local.bgsave_health status CRITICAL. Rasanya kayak lagi santai minum kopi, tiba-tiba alarm mobil bunyi di tengah malam. Kamu pasti langsung panik dan mikir, “Redis-ku kenapa?”

Jadi begini, Redis itu semacam gudang penyimpanan data super cepat yang dipakai oleh banyak aplikasi — mulai dari session management, caching, sampai message broker. Kalau Redis-nya bermasalah, dampaknya bisa ke mana-mana. Website bisa lambat, aplikasi bisa error, bahkan fitur tertentu bisa completely down. Dan notifikasi redis_local.bgsave_health yang muncul di Netdata itu sebenarnya adalah alarm yang mengatakan bahwa proses backup data Redis (yang namanya RDB save atau bgsave) mengalami kegagalan. Ini bukan sekadar alarm biasa — ini tanda bahwa data di Redis-mu berpotensi hilang kalau server restart mendadak.

Sebagai NOC engineer yang sudah menangani ratusan server, saya bisa bilang: masalah ini sebenarnya cukup umum terjadi, terutama di server yang menjalankan CyberPanel atau panel hosting lainnya. Penyebabnya bermacam-macam, mulai dari Redis yang kehabisan memori, konfigurasi yang salah, sampai service autom8redis yang perlu di-restart. Yang penting, jangan panik dulu. Ikuti langkah-langkah di bawah ini dan kamu bisa fix masalah ini dalam hitungan menit.

Notifikasi lengkap yang biasanya muncul di Netdata terlihat seperti ini:

server.iixcp.domainku.net is critical - redis bgsave broken
redis_local.bgsave_health
Redis background save = ok
Status of the last RDB save operation (0: ok, 1: error)

Meskipun di log tertulis Redis background save = ok, status alarm tetap CRITICAL. Ini terjadi karena Netdata mendeteksi bahwa proses bgsave sebelumnya pernah gagal, dan statusnya belum di-reset. Kadang memang Netdata agak “nyangkut” dan butuh restart service Redis supaya alarm-nya clear. Nah, ini yang sering bikin bingung engineer junior — kok statusnya ok tapi alarm-nya tetap critical? Jawabannya: Netdata cache status bgsave dan perlu restart supaya statusnya refresh.

Kenapa Redis Bgsave Bisa Broken?

Sebelum kita masuk ke solusi, penting untuk paham dulu kenapa masalah ini bisa terjadi. Bgsave (background save) adalah mekanisme Redis untuk membuat snapshot data ke disk secara periodik. Kalau kamu punya konfigurasi save 900 1 di redis.conf, itu artinya Redis akan otomatis save data ke disk setiap kali ada minimal 1 key yang berubah dalam 900 detik terakhir. Proses save ini berjalan di background, makanya namanya bgsave.

Ketika bgsave gagal, beberapa hal bisa terjadi:

• Kekurangan disk space — Redis tidak bisa menulis file .rdb ke disk karena kapasitas penuh
• Kekurangan memori (fork issue) — Proses bgsave membutuhkan fork(), yang artinya Redis perlu duplikasi memory usage. Kalau Redis pakai banyak RAM, fork bisa gagal
• Permission issue — Redis tidak punya permission untuk menulis ke direktori tertentu
• Corrupt RDB file — File dump.rdb yang sudah ada mengalami kerusakan
• Service autom8redis bermasalah — Di server CyberPanel, ada service tambahan seperti autom8redis_broker dan autom8redis_taskq yang bisa menyebabkan konflik

Di kasus yang sering saya temui, masalahnya bukan di Redis-nya langsung, melainkan di service pendukung seperti autom8redis_broker dan autom8redis_taskq. Kedua service ini berjalan sebagai message broker untuk CyberPanel dan kadang mengalami deadlock atau connection pool exhaustion yang mengganggu operasi Redis utama.

Gejala dan Error Message

Berikut adalah gejala yang biasanya muncul ketika Redis bgsave mengalami masalah:

Solusi: Restart Redis dan Service Terkait

Oke, langsung ke solusi. Berdasarkan pengalaman saya di lapangan, langkah paling efektif untuk mengatasi redis_local.bgsave_health CRITICAL adalah melakukan restart pada tiga service sekaligus. Bukan cuma Redis-nya saja, tapi juga service autom8redis yang mendukungnya.

Langkah 1: Cek Status Redis Saat Ini

Sebelum restart, cek dulu status Redis yang berjalan:

systemctl status redis

Perhatikan outputnya. Kalau statusnya active (running) tapi ada error di bagian log, itu tandanya Redis berjalan tapi ada masalah internal. Kalau statusnya inactive (dead) atau failed, itu masalah yang lebih serius.

Langkah 2: Cek Socket Redis

Di server CyberPanel atau DirectAdmin yang menggunakan custom Redis socket, pastikan socket Redis-nya aktif:

ls -la /home/userpanel/tmp/redis.sock

Socket file ini penting karena banyak aplikasi yang terhubung ke Redis melalui Unix socket (bukan TCP port). Kalau socket-nya hilang atau corrupt, restart Redis saja tidak cukup — kamu juga perlu memastikan aplikasi bisa reconnect ke socket yang baru.

redis-cli -s /home/userpanel/tmp/redis.sock ping

Expected output: PONG. Kalau kamu dapat response PONG, berarti Redis masih merespons. Kalau error atau timeout, Redis memang perlu di-restart.

Langkah 3: Restart Tiga Service Sekaligus

Ini adalah langkah utama. Jalankan ketiga perintah restart ini secara berurutan:

systemctl restart redis
systemctl restart autom8redis_broker
systemctl restart autom8redis_taskq

Kenapa harus ketiganya? Karena service autom8redis_broker dan autom8redis_taskq saling terhubung dengan Redis utama. Kalau kamu cuma restart Redis tapi tidak restart kedua service ini, bisa terjadi kondisi di mana Redis sudah fresh tapi autom8redis masih pegang koneksi lama yang sudah stale. Akibatnya? Bgsave tetap gagal karena ada konflik koneksi.

Setelah menjalankan perintah di atas, tunggu sekitar 10-30 detik supaya semua service bisa initialize dengan sempurna.

Langkah 4: Verifikasi Status

Setelah restart, verifikasi bahwa semuanya sudah berjalan normal:

systemctl status redis
systemctl status autom8redis_broker
systemctl status autom8redis_taskq

Ketiga service harus menunjukkan status active (running). Kalau ada yang masih failed, cek log-nya:

journalctl -u redis --since "5 minutes ago" --no-pager
journalctl -u autom8redis_broker --since "5 minutes ago" --no-pager
journalctl -u autom8redis_taskq --since "5 minutes ago" --no-pager

Langkah 5: Test Bgsave Manual

Untuk memastikan bgsave berfungsi, jalankan perintah save manual:

redis-cli -s /home/userpanel/tmp/redis.sock bgsave

Expected output: Background saving started. Tunggu beberapa detik, lalu cek apakah file dump.rdb ter-update:

ls -la /var/lib/redis/dump.rdb

Timestamp file dump.rdb harus menunjukkan waktu yang baru (beberapa detik yang lalu). Kalau timestamp-nya masih lama, ada masalah lain yang perlu diinvestigasi lebih lanjut.

Langkah 6: Tunggu Netdata Clear Alarm

Setelah bgsave berhasil, biasanya Netdata akan otomatis clear alarm dalam beberapa menit. Kamu bisa cek di dashboard Netdata untuk memastikan. Kalau alarm masih muncul setelah 5-10 menit, kamu bisa clear manual dari command line:

curl -s "http://localhost:19999/api/v1/alarm?all" | grep bgsave

Atau restart Netdata agent supaya alarm-nya refresh:

systemctl restart netdata

Di atas adalah ilustrasi dashboard Netdata ketika alarm bgsave masih aktif. Setelah kamu melakukan restart dan verifikasi, status ini akan berubah menjadi OK.

Troubleshooting: Kalau Masih Gagal Setelah Restart

Kadang restart saja tidak cukup. Berikut adalah beberapa masalah lanjutan yang mungkin kamu hadapi dan cara mengatasinya:

Kasus: vm.overcommit_memory

Ini adalah masalah yang cukup sering terjadi di server dengan RAM terbatas. Ketika Redis mencoba melakukan bgsave, ia perlu melakukan operasi fork() untuk menduplikasi process. Kalau Linux menolak alokasi memori tambahan, bgsave akan gagal.

Cek apakah ini masalahnya:

cat /proc/sys/vm/overcommit_memory

Kalau output-nya 0, itu berarti Linux menggunakan heuristik default yang bisa menolak fork. Untuk Redis, disarankan untuk set ke 1:

echo 1 > /proc/sys/vm/overcommit_memory

Untuk membuat permanen:

echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf
sysctl -p

Pro Tips dari NOC Engineer

Perintah Cheat Sheet

Mencegah Masalah Ini Terulang

Setelah kamu fix masalah ini, ada beberapa hal yang bisa kamu lakukan untuk mencegahnya terulang:

1. Monitor disk space secara rutin — Setup alerting di Netdata untuk disk usage. Kalau disk sudah mencapai 80%, sudah waktunya untuk cleanup.
2. Set maxmemory di Redis — Agar Redis tidak menggunakan seluruh RAM server. Edit /etc/redis.conf dan set maxmemory 2gb (sesuaikan dengan kebutuhan).
3. Gunakan AOF (Append Only File) — Selain RDB snapshot, aktifkan AOF sebagai backup tambahan. Edit /etc/redis.conf dan set appendonly yes.
4. Setup cron untuk restart berkala — Beberapa engineer membuat cron job untuk restart Redis setiap minggu di jam sepi. Ini bisa mencegah memory leak yang terakumulasi.
5. Update Redis ke versi terbaru — Beberapa bug di versi lama sudah diperbaiki di versi baru.

Jika kamu ingin mempelajari lebih lanjut tentang monitoring server, cek juga artikel tentang cara lengkap monitoring server dengan Netdata. Dan untuk masalah serupa terkait service lain, panduan restart service di Linux dengan systemctl bisa jadi referensi tambahan.

Nah, itu dia cara mengatasi redis_local.bgsave_health CRITICAL di Netdata. Intinya: jangan panik, cek dulu kondisi disk dan memori, lalu restart ketiga service (redis, autom8redis_broker, autom8redis_taskq) secara berurutan. Dalam kebanyakan kasus, ini sudah cukup untuk clear alarm dan mengembalikan Redis ke kondisi normal.

Kalau kamu mengalami masalah yang lebih kompleks — misalnya Redis terus-terusan crash atau data hilang — mungkin waktu untuk setup monitoring yang lebih baik atau konsultasi dengan tim managed server professional. Jangan biarkan masalah kecil menjadi besar hanya karena ditunda-tunda.