Redis is a well-known key-value open-source database spreadly used in cloud-native applications. In this article, we’ll cover how it’s possible to monitor Redis with IBM Cloud Monitoring and the key metrics to look into.
Since Redis has become a key component for many cloud applications, performance issues may arise and can cause other applications’ components to fail. Knowing how to monitor Redis and getting alerted using IBM Cloud Monitoring out-of-the-box integration will ensure keeping the infrastructure up & running at top speed.
On the other hand, if the Redis instance is deployed as a Redis managed service on IBM Cloud, it’s also possible to monitor it. To do that, enabling the Platform Metrics feature is required in the IBM Cloud account. These metrics will expose out-of-the-box Redis metrics that can be consumed within the IBM Cloud Monitoring solution. Check the complete documentation here: https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-monitoring
How to enable the Redis monitoring integration
Since Prometheus has become the de-facto monitoring application in Kubernetes environments, it’s possible to use a Redis exporter to expose Prometheus metrics that can be collected by Prometheus. Although using the open-sourced version is a perfectly fine approach, IBM Cloud Monitoring offers an out-of-the-box monitoring integration that allows deploying this integration in an easy and guided way.
Fig.: Redis integration configuration form within Integrations > Monitoring Integrations.
The first step, and almost the default one for each database engine exporter, is to create a read-only user that will be used to collect & generate the Prometheus metrics. This user must have enough privileges to read Redis stats and generate(and expose) Prometheus metrics that the IBM Cloud Monitoring agent will collect.
It’s possible to use the Redis cli and run the following command to create that user:
ACL SETUSER USERNAME +client +ping +info +config|get +cluster|info +slowlog +latency +memory +select +get +scan +xinfo +type +pfcount +strlen +llen +scard +zcard +hlen +xlen +eval allkeys on >PASSWORD
Note: update “username” and “password” by the desired values.
Next, let’s store that read-only user password in a Kubernetes secret within the same namespace where the Redis exporter will be deployed:
kubectl create -n Your-Application-Namespace secret generic redis-exporter-auth \
--from-literal=user=USER \
--from-literal=password=PASSWORD
The second step just requires to fill a couple of fields in the following form:
Note: remember to set the correct REDIS_ADDR endpoint targeting your Redis instance.
Finally, it’s time to deploy the Redis exporter using the configuration defined. It’s possible to deploy it using Helm or Kubectl; it just depends on the preferred flavor.
Once the deployment has been deployed, just click “Validate” and wait some minutes to start seeing the new metrics coming to the IBM Cloud Monitoring instance.
After the first metrics flowing to the IBM Cloud Monitoring instance, a new Redis dashboard will be available under Dashboards > Dashboards Library > Applications > Redis.
Fig.: Redis out-of-the-box dashboard
Also, a new out-of-the-box set of alerts will be available for Redis under Alerts > Library > Redis.
Fig.: Alerts library for Redis monitoring integration
Top 3 Redis performance metrics
Cache hit ratio
Redis uses an in-memory cache to accelerate the response time and improve performance. A low hit ratio means that, for any reason, the database isn’t behaving as expected, which means that the performance is poor, increasing the response time and latency.
Based on the exposed metrics, it’s possible to calculate the cache hit ratio using the following PromQL query:
(rate(redis_keyspace_hits_total[5m])
/ (rate(redis_keyspace_misses_total[5m])
+ rate(redis_keyspace_hits_total[5m])))
Note: An average value should go over 0.9.
It’s possible to use the metric redis_evicted_keys_total to monitor the number of keys being evicted from the in-memory cache to disk. To do that, just perform the following query:
rate(redis_evicted_keys_total[5m])
Tip: If an alert is needed when a low hit ratio happens, just enable the “Low Hit Ratio” out-of-the-box alert in the Redis alerts library.
Slow queries & latency
Like other database engines, Redis registers those queries taking more time than a defined threshold, also known as “slow queries”, to be performed. Those queries can produce high latency issues.
Redis exporter exposes several metrics to measure those slow queries; one of them is the redis_slowlog_length metric. It’s possible to monitor this metric with the following PromQL query:
rate(redis_slowlog_length[5m])
Also, it’s possible to calculate the average response time of the Redis server with two extra metrics: redis_commands_duration_seconds_total and redis_commands_processed_total metrics.
As a good practice, an alert can be triggered if the average response time is over 250ms doing the following:
(rate(redis_commands_duration_seconds_total[5m]) / rate(redis_commands_processed_total[5m]) ) > 0.250
Memory usage
A high cache hit ratio or many evicted keys can be a symptom of low available memory.
Thanks to redis_memory_max_bytes and redis_memory_used_bytes metrics, it’s possible to assess the memory usage of the Redis server:
100 * redis_memory_used_bytes / redis_memory_max_bytes
Looking for Redis memory optimization, it’s possible to use the redis_mem_fragmentation_ratio metric to check the fragmentation ratio.
Tip: If an alert to control the memory spikes is needed, just enable the “High Memory Usage” out-of-the-box alert in the Redis alerts library and set the desired threshold.