Redis monitoring

Redis began as a caching database, but it has since evolved into a primary database. Many applications built today use Redis as a primary database. However, most Redis service providers support Redis as a cache but not as a primary database.

With Redis Enterprise, you can use Redis as both an in-memory cache and a primary database in a single system, thus eliminating the complexity and latency of two separate systems. Not only that, you can use it as a multi-model primary database, enabling you to build modern applications, as well as low-latency microservice-based architectures, all on top of Redis.

See: Redis as a Cache vs Redis as a Primary Database in 90 Seconds | Redis

Redis is an open source, in-memory key-value data structure store, which can be used as a database, cache, or message broker. It's a NoSQL database.

eG Enterprise supports over 200 different technology stacks, see: End-to-End Monitoring: Applications, Cloud, Containers (eginnovations.com), including many popular database offerings such as: MongoDB, Maria, Oracle, Microsoft SQL Server, Azure SQL Managed Instances and Database, Azure Cosmos DB, SAP HANA, MySQL and others.

The Redis architecture contains two main processes: Redis client and Redis Server. Redis client and server can be on the same computer or VM / container or on distinct separate computers/VMs.

Redis server is responsible for storing data in memory. It handles all kinds of management and forms the major part of the Redis architecture. Redis client can be Redis console client or any other programming language’s Redis API.

Redis is a storage of data structures of the NoSQL type. Redis stores everything in primary operational memory. Primary memory is volatile and therefore we will lose all stored data once we restart our Redis server or computer. Therefore, for data persistence, Redis supports the following mechanisms:

• RDB: At specified intervals, RDB makes a copy of all the data in memory and stores them in permanent storage.
• AOF: AOF logs all write operations received by the server, thereby making all data persistent.
• SAVE command: Redis server can be forced to create an RDB snapshot any time using the SAVE command.

Redis also supports replication for fault-tolerance and data accessibility. To enhance storage capacity, you can also group two or more Redis servers to form a cluster. As such, Redis employs a primary-replica architecture and supports asynchronous replication where data can be replicated to multiple replica servers. This provides improved read performance as requests can be split and distributed amongst the servers and enables faster recovery when the primary server experiences an outage.

An excellent community article on Redis terminology and architectures is, How Redis Internally works ? What is redis ? | by N Singh | Nov, 2022 | Medium.

As mentioned already, all Redis data resides in-memory, in contrast to databases that store data on disk or SSDs. By eliminating the need to access disks, in-memory data stores such as Redis avoid seek time delays and can access data in microseconds.

Because of the reduced seek time and improved accessibility of data, Redis is the 'go-to' database for search engines.

Also, Redis supports Pub/Sub with pattern matching and a variety of data structures such as lists, sorted sets, and hashes. This allows Redis to support high performance chat rooms, real-time comment streams, social media feeds and server intercommunication such as Twitter, Flickr, Pinterest etc.

To summarize, many widely popular applications rely on Redis for their data storage and retrieval needs. This means that even a short break in the availability of the database or any slowness in its performance, no matter how negligible, can adversely impact user experience with that business-critical application. To avoid this, administrators should continuously monitor the health and performance of the Redis server and capture performance issues, well before they impact the quality of user interactions with the dependent applications.

eG Enterprise’s proactive monitoring and out-of-the-box alerting ensures administrators can avoid most issues and outages and when issues do impact performance resolve them rapidly.

Third-party platforms such as eG Enterprise simplify the monitoring of Redis Servers. Redis does provide some functionality to access performance data and metrics directly. MONITOR is a debugging command that streams back every command processed by the Redis server. It can help in understanding what is happening to the database. This command can both be used via redis-cli and via telnet. See: MONITOR | Redis.

Yes, it does. You can read more about support in our documentation, see: Azure Redis Cache Test (eginnovations.com).

Using eG Enterprise for Redis, administrators can find quick and accurate answers to the following common performance questions:

• Is the Redis server available over the network?
• Is the server responding to a ping request with a pong?
• Did the server reboot recently? If so, was it a scheduled or unscheduled reboot?
• Is any client connection to Redis been idle for too long a time? If so, what is that client's IP address?
• Which are the long running client connections to the Redis server?
• Did the server reject any connections to it because the maxclients limit was reached?
• Is there enough space in the Redis query buffer? Which client's query buffer is running out space?
• Is the output list of any client very long? If so, which client has a long output list? Is the abnormal output list length because of lack of memory in the output buffer of that client?
• Is the Redis server consuming CPU excessively? If so, what is contributing to this erratic CPU usage - resource-intensive system processes? or resource-hungry user processes?
• Is the server about to exhaust its maxmemory limit?
• Has high memory fragmentation been noticed on the server?
• Is the server overloaded with commands to be processed?
• Has any command been CPU-intensive consistently?
• Has the Slowlog captured any slow commands? If so, which are these commands and when were they executed?
• Are keys in any Redis database expiring soon? If so, which database do these keys belong to?
• Have many keys expired?
• Have any keys been evicted?
• Is the keyspace able to service all requests to it, or are too many keyspace hits going unserviced? Is the poor hit ratio increasing server latency?
• Did the last RDB save operation take too long to complete?
• Has it been a long time since the last successful RDB save operation occurred?
• Is Append Only File (AOF) logging enabled on the server?
• Is the target Redis server the master or slave in a replication configuration?
• If the target is a slave, then is it able to connect to the master? Has the link to the master been down too long?
• Is the slave syncing with the master very slowly?
• Is the replication backlog rightly sized?
• Are more full synchronizations occurring than partial synchronizations?
• Have any partial synchronization attempts failed?
• Is the monitored Redis instance part of a cluster? If so, is the cluster operating normally at present?
• Are any hash slots in the cluster in the FAIL or PFAIL state?
• Were any nodes recently added to or deleted from the cluster? If so, which nodes are these?

Yes, the core eG Enterprise product includes both live and historical reporting, out-of-the-box alongside a simple to use GUI custom report builder allow you to schedule and generate reports for auditing, KPI and SLA tracking and management insight. Long term trends and usage patterns can be analyzed and tracks to allow you to plan your Redis infrastructure.