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.
# 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
slaveof 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 #
Now please have a look at the screenshot below.
As you see, it works!
Monitoring Redis with Monitis
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.
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.
The graphic below shows the variation of values of four metrics over the period of a few hours.
As you can see, there is a listbox to the left of the graphic in which you can select the metrics you want to track.