Monitoring Redis Database with Monitis

Among other NoSQL databases there is a particularly nice one called REDIS.

 

It’s an open source and advanced key-value store database. What is meant by ‘advanced’ here? Redis keys can contain strings, hashes, lists, sets and sorted sets on which you can run atomic operations. It also works with an in-memory dataset, supports master slave replication and is equally useful for tiny projects running on a single VPS as it is for huge services running across dozens of servers.

 

But we are not going to discuss the features of Redis here, because those are already well covered in many other articles, every day.

 

The aim of this article is show you how it is possible to monitor a Redis server with Monitis.
For that purpose we will install a small cluster of 3 nodes (1 master & 2 slaves).
Of course, there is no need to install the whole cluster to show how to monitor Redis, but it is interesting, isn’t it?

 

So, Ubuntu 11.10 will be used for our installation.

 

Installation

 

# apt-get install redis-server

 

After installation is complete, we need to create configuration files for each instance of Redis.
Please note that this is just an example, you are free to set your own settings.

 

# vi /etc/redis/redis_master.conf

daemonize yes

pidfile /var/run/redis_master.pid

port 6370 

bind 192.168.10.240

timeout 300

loglevel notice

logfile /var/log/redis/redis_master.log

databases 16

save 900 1

save 300 10

save 60 10000

rdbcompression yes

dbfilename dump.rdb

dir /var/lib/redis/master

slave-serve-stale-data yes

appendonly no

appendfsync everysec

no-appendfsync-on-rewrite no

vm-enabled no

vm-swap-file /var/lib/redis/redis_master.swap

vm-max-memory 0

vm-page-size 32

vm-pages 134217728

vm-max-threads 4

hash-max-zipmap-entries 512

hash-max-zipmap-value 64

list-max-ziplist-entries 512

list-max-ziplist-value 64

set-max-intset-entries 512

activerehashing yes

#
# vi /etc/redis/redis_slave1.conf

daemonize yes

pidfile /var/run/redis_slave1.pid

port 6371

bind 127.0.0.1

timeout 300

loglevel notice

logfile /var/log/redis/redis_slave1.log

databases 16

save 900 1

save 300 10

save 60 10000

rdbcompression yes

dbfilename dump.rdb

dir /var/lib/redis/slave1

slave-serve-stale-data yes

appendonly no

appendfsync everysec

no-appendfsync-on-rewrite no

vm-enabled no

vm-swap-file /var/lib/redis/redis_slave1.swap

vm-max-memory 0

vm-page-size 32

vm-pages 134217728

vm-max-threads 4

hash-max-zipmap-entries 512

hash-max-zipmap-value 64

list-max-ziplist-entries 512

list-max-ziplist-value 64

set-max-intset-entries 512

activerehashing yes

slaveof 192.168.10.240 6370

#
# vi /etc/redis/redis_slave2.conf

daemonize yes

pidfile /var/run/redis_slave2.pid

port 6372

bind 127.0.0.1

timeout 300

loglevel notice

logfile /var/log/redis/redis_slave2.log

databases 16

save 900 1

save 300 10

save 60 10000

rdbcompression yes

dbfilename dump.rdb

dir /var/lib/redis/slave2

slave-serve-stale-data yes

appendonly no

appendfsync everysec

no-appendfsync-on-rewrite no

vm-enabled no

vm-swap-file /var/lib/redis/redis_slave2.swap

vm-max-memory 0

vm-page-size 32

vm-pages 134217728

vm-max-threads 4

hash-max-zipmap-entries 512

hash-max-zipmap-value 64

list-max-ziplist-entries 512

list-max-ziplist-value 64

set-max-intset-entries 512

activerehashing yes

 

slave of 192.168.10.240 6370
The bold text shows the difference between the configuration files.
Now we have to create the directories that we set as dir in configs.

 

# mkdir /var/lib/redis/master /var/lib/redis/slave1 /var/lib/redis/slave2

 

And set vm.overcommit_memory = 1 in /etc/sysctl.conf  since background save may fail under a low memory condition.Okay, now we are ready to go. Run the servers:

 

#
# redis-server /etc/redis/redis_master.conf
# redis-server /etc/redis/redis_slave1.conf
# redis-server /etc/redis/redis_slave2.conf
#

 

 

It works!

Monitoring Redis with Monitis

 

And Monitis M3 will help us. The installation process of M3 is already described, so we will just review some metrics whose descriptions are given on the official site.

 

used_memory is the total number of bytes allocated by Redis using its allocator (either standard libc malloc, or an alternative allocator such as tcmalloc).

 

used_memory_rss is the number of bytes that Redis allocated as seen by the operating system. Optimally, this number is close to the used_memory value and there is little memory fragmentation.

 

These are the numbers reported by tools such as top and ps. A large difference between these numbers means there is memory fragmentation. Since Redis does not have control over how its allocations are mapped to memory pages, the used_memory_rss value is often the result of a spike in memory usage. The ratio between used_memory_rss and used_memory is given in  mem_fragmentation_ratio.

 

changes_since_last_save refers to the number of operations that produced some kind of change in the dataset since the last time either SAVE or BGSAVE was called.

 

allocation_stats holds a histogram containing the number of allocations of a certain size (up to 256).

 

This provides a means of introspection for the type of allocations performed by Redis at run time.
I couldn’t find any descriptions for other metrics on the official site and digging through the source code gave me nothing either.

However, some metrics are simple and straightforward, while for others I spent a lot of time figuring out the meanings of the metrics which are useful for monitoring.

 

uptime_in_seconds: shows how many seconds redis is up
connected_clients: shows the number of connected clients
connected_slaves: shows the number of connected slaves
blocked_clients: shows number of blocked clients. See BLPOP
used_memory_human: same as used_memory, but in human readable form (e.g. when used_memory = 7340032 it may be difficult to determine if it is in KB or MB. So, the used_memory_human gives a more understandable view: used_memory_human = 7KB)
last_save_time: last time (in UNIX timestamp format) that Redis saved all the data inside the Redis instance, in the form of an RDB file.
total_connections_received: total number of connections
total_commands_processed: total commands processed
expired_keys: expired keys count
When new data is added to the server, and the memory limit has already been reached, the server will remove some old data by deleting a volatile key, that is, a key with an EXPIRE (a timeout) set, even if the key is still far from expiring automatically.
evicted_keys: the number of keys that have been evicted (removed).

 

keyspace_hits, keyspace_misses: These metrics are for managing the performance of the Redis datastore. Track these metrics to determine the number being served directly from the store, and the performance rate.
hash_max_zipmap_entries – if hash fields are less than this value then the optimized method is used
hash_max_zipmap_value – if hash values sizes are less than this value then the optimized method is used. See more about hash optimization.

 

Redis has built-in Publishing / Subscribe / Messaging support which enables high performance networking solutions to be developed. PUBLISH/SUBSCRIBE operations allow any number of clients to be able to listen on any named channel. When an external client publishes a message to that channel, each listening client is notified. The clients will continue to receive messages as long as they maintain at least one active subscription.
The next two metrics show the channels and patterns counts, respectively.

 

pubsub_channels, pubsub_patterns: See more about Publish/Subscribe messaging paradigm.

 

 

 

You might also like