Monitoring

Monitoring adalah kegiatan membaca kondisi server Redis dari dalam, sebelum masalahnya terlihat dari luar sebagai kegagalan aplikasi. Topik ini membahas tiga alat bawaan yang paling sering digunakan, yaitu INFO untuk ringkasan kondisi server, slowlog untuk mencatat perintah yang lambat, dan MEMORY USAGE untuk menakar ukuran key. Seluruh contoh dijalankan pada server lab terisolasi di port 6389 menggunakan key berawalan mon:, dengan ambang slowlog 100 mikrodetik yang dipasang saat lab dinyalakan. Setelah membacanya, big key dan sumber latensi yang paling lazim dapat dicari dengan urutan pemeriksaan yang jelas.

Server lab dinyalakan dengan blok berikut. Ambang slowlog dan panjang catatannya dipasang sebagai argumen server, sehingga tidak ada pengaturan tambahan yang perlu dijalankan setelahnya.

# hentikan sisa server lab monitoring bila masih berjalan
redis-cli -p 6389 shutdown nosave 2>/dev/null || true
# siapkan folder kerja lab
mkdir -p /tmp/lab-mon
# nyalakan server lab dengan ambang slowlog 100 mikrodetik
redis-server --port 6389 --bind 127.0.0.1 --daemonize yes --dir /tmp/lab-mon --save "" --slowlog-log-slower-than 100 --slowlog-max-len 32 --protected-mode no --logfile /tmp/lab-mon-server.log
sleep 1
redis-cli -p 6389 ping

PONG

Membaca kondisi server dengan INFO#

Perintah INFO mengembalikan laporan kondisi server dalam bentuk blok teks yang terbagi atas bagian, seperti server, memory, dan stats. Keluaran mentahnya panjang dan berubah terus seiring berjalannya server, sehingga cara membacanya adalah memilih bagian tertentu lalu menyaring baris yang relevan. Blok berikut mengambil dua baris penting dari bagian memory pada server lab yang baru dinyalakan oleh blok sebelumnya. Baris used_memory_human sengaja tidak ikut diambil karena nilainya berubah sedikit demi sedikit bahkan saat server tanpa beban, sedangkan baris yang diambil bernilai tetap selama labnya sama.

# beberapa baris tetap dari bagian memory
redis-cli -p 6389 info memory | grep -E '^(maxmemory_human|maxmemory_policy):'

maxmemory_human:0B
maxmemory_policy:noeviction

Angka pada keluaran mudah dibaca. maxmemory_human berisi 0B karena lab ini tidak memasang batas memori, sedangkan maxmemory_policy berisi noeviction, yaitu kebijakan bawaan yang menolak penulisan baru ketika memori penuh alih-alih menghapus key lain. Bagian stats dan server menyediakan baris lain yang berguna, seperti total_commands_processed untuk banyaknya perintah yang diproses, keyspace_hits dan keyspace_misses untuk keberhasilan pembacaan, serta evicted_keys untuk key yang dibuang oleh eviksi. Baris-baris itu tidak disertakan pada demo karena nilainya bergerak mengikuti beban, sehingga pembacaannya bermakna hanya bila dilakukan berkala pada server yang sama.

Mencatat perintah lambat dengan slowlog#

Slowlog adalah catatan internal Redis atas perintah yang durasi eksekusinya melampaui ambang tertentu. Ambangnya diatur saat server dinyalakan, dan lab ini menggunakan 100 mikrodetik agar perintah lambat yang disimulasikan pasti terekam. Jumlah entrinya dibatasi pula, pada lab ini 32 entri terbaru, sehingga catatan lama tergeser oleh yang baru, sedangkan panjang catatan pada suatu saat dapat dibaca dengan SLOWLOG LEN. Blok berikut mengosongkan catatan terlebih dahulu, lalu menjalankan satu perintah EVAL yang mendorong 50000 item ke dalam sebuah list.

# kosongkan slowlog agar isi demo selalu sama
redis-cli -p 6389 slowlog reset
# satu perintah EVAL berisi 50000 RPUSH: pasti melampaui ambang 100 mikrodetik
redis-cli -p 6389 eval "for i=1,50000 do redis.call('RPUSH', KEYS[1], i) end return redis.call('LLEN', KEYS[1])" 1 mon:antrean

OK
50000

Keluaran memperlihatkan bahwa perintah EVAL tadi terekam di slowlog. Setiap entri slowlog memuat beberapa kolom, yaitu penomoran entri, waktu terjadinya dalam bentuk waktu unix, durasi eksekusi dalam mikrodetik, perintah lengkap beserta argumennya, dan alamat klien yang mengirimkannya. Kolom waktu dan durasi berubah pada setiap eksekusi, sehingga demo berikut menyaring baris perintahnya saja agar keluarannya tetap stabil.

# tampilkan baris perintah EVAL dari entri slowlog
redis-cli -p 6389 slowlog get | grep -E '^(eval|for i=1)'

eval
for i=1,50000 do redis.call('RPUSH', KEYS[1], i) end return redis.call('LLEN', KEYS[1])

Entri ini menunjukkan pola yang sama dengan kasus nyata, yaitu satu perintah yang terlihat sepele ternyata mengerjakan pekerjaan besar di dalamnya. Perintah lambat yang terekam hampir selalu berasal dari dua sumber, yaitu perintah yang memproses banyak item sekaligus dan perintah yang menyentuh key berukuran besar. Kedua sumber itu dapat diperbaiki dengan memecah pekerjaan menjadi kelompok kecil atau dengan menata ulang bentuk datanya.

Mengukur big key dengan MEMORY USAGE#

Big key adalah key yang nilainya jauh lebih besar daripada key lain pada basis data yang sama. Key semacam ini memengaruhi dua hal sekaligus, yaitu memori yang timpang antar key dan latensi operasi atas key itu sendiri, karena membaca atau menghapus nilai berukuran besar membutuhkan waktu lebih lama. Perintah MEMORY USAGE memperkirakan jumlah byte yang digunakan sebuah key, termasuk overhead struktur internalnya, sehingga perbandingan antar key menjadi adil. Blok berikut membuat dua string berukuran kontras, lalu menakar ketiga key yang ada di lab.

# string kecil untuk pembanding
redis-cli -p 6389 set mon:key-kecil "abc"
# string besar berisi tiga juta karakter
head -c 3000000 /dev/zero | tr '\0' a | redis-cli -p 6389 -x set mon:string-besar
# ukuran memori ketiga key di lab
redis-cli -p 6389 memory usage mon:key-kecil
redis-cli -p 6389 memory usage mon:string-besar
redis-cli -p 6389 memory usage mon:antrean

OK
OK
72
3145792
182591

Angka pada keluaran memperlihatkan dua hal yang tidak selalu sesuai perkiraan. String besar memakan 3145792 byte, sedikit di atas tiga juta byte karakternya karena overhead alokasi memori. Sebaliknya, list dengan 50000 item hanya memakan 182591 byte, jauh lebih kecil daripada string besar tersebut, karena list menyimpan tiap item sebagai elemen kecil yang padat. Perbandingan ini menegaskan bahwa ukuran key tidak selalu mengikuti jumlah item yang terlihat, dan pengukuran dengan MEMORY USAGE lebih dapat diandalkan daripada perkiraan.

Pencarian big key biasanya dilakukan tanpa mengetahui namanya terlebih dahulu. Opsi --bigkeys pada redis-cli memindai seluruh keyspace menggunakan SCAN, lalu melaporkan key terbesar untuk setiap tipe beserta ringkasannya. Demo berikut menampilkan bagian ringkasannya saja.

# pindai keyspace lab, tampilkan ringkasan key terbesar per tipe
redis-cli -p 6389 --bigkeys | sed -n '/-------- summary -------/,$p'

-------- summary -------

Sampled 3 keys in the keyspace!
Total key length in bytes is 42 (avg len 14.00)

Biggest   list found "mon:antrean" has 50000 items
Biggest string found "mon:string-besar" has 3000000 bytes

1 lists with 50000 items (33.33% of keys, avg size 50000.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
2 strings with 3000003 bytes (66.67% of keys, avg size 1500001.50)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

Ringkasan pada keluaran menunjuk langsung dua key yang patut dicurigai, yaitu string berisi tiga juta karakter dan list berisi 50000 item. Pemindaian semacam ini aman dijalankan pada server yang sedang melayani beban karena berbasis SCAN, yang berjalan bertahap tanpa menghentikan server.

Latensi sisi server dan disiplin pemantauan#

Selain perintah yang lambat, latensi juga dapat muncul dari peristiwa di sisi server, misalnya pembuatan proses anak (fork) saat persistensi berjalan atau pembebasan key besar saat eviksi. Redis menyediakan subsistem LATENCY untuk peristiwa semacam ini, dengan perintah seperti LATENCY LATEST dan LATENCY HISTORY untuk membaca peristiwa yang terekam. Monitor latensi ini tidak aktif sebelum ambangnya diatur melalui latency-monitor-threshold, dan topik ini cukup menyinggung keberadaannya karena slowlog sudah menutupi sisi perintah yang paling sering bermasalah.

Alat di atas hanya berguna bila pemeriksaannya dilakukan secara rutin. Disiplin yang lazim terdiri atas tiga kebiasaan, yaitu membaca bagian INFO yang relevan dengan ambang yang disepakati, meninjau slowlog pada interval tetap, dan mengukur big key sebelum memori benar-benar habis. Ketiganya dilakukan dari redis-cli tanpa alat tambahan, sehingga dapat dijalankan pada server mana pun yang dapat dijangkau. Lab pada topik ini selesai digunakan, sehingga servernya dimatikan dengan blok berikut.

# matikan server lab monitoring
redis-cli -p 6389 shutdown nosave

Ringkasan#

• INFO menyajikan kondisi server per bagian, dan baris seperti maxmemory_policy, total_commands_processed, serta keyspace_hits dibaca secara berkala agar perubahan terlihat.
• Slowlog mencatat perintah yang melampaui ambang durasinya, dengan kolom waktu, durasi mikrodetik, perintah lengkap, dan alamat klien pada tiap entrinya.
• MEMORY USAGE menakar byte yang digunakan sebuah key termasuk overhead strukturnya, sedangkan --bigkeys menemukan key terbesar per tipe di seluruh keyspace secara bertahap.
• Latensi sisi server seperti fork dan eviksi dipantau oleh subsistem LATENCY yang baru aktif setelah ambangnya diatur.

Referensi#

• INFO — Redis — Daftar bagian dan kolom laporan INFO, termasuk bagian memory dan stats yang digunakan di topik ini.
• SLOWLOG GET — Redis — Format entri slowlog beserta kolom waktu, durasi mikrodetik, perintah, dan alamat klien.
• MEMORY USAGE — Redis — Perkiraan penggunaan memori sebuah key beserta opsi SAMPLES untuk tipe bertumpuk.
• LATENCY HISTORY — Redis — Membaca riwayat peristiwa latensi sisi server yang terekam oleh monitor latensi.