{"id":3372,"date":"2020-12-01T13:13:02","date_gmt":"2020-12-01T13:13:02","guid":{"rendered":"https:\/\/contentlab.com\/monitoring-redis-database-performance-with-new-relic\/"},"modified":"2021-11-11T04:05:11","modified_gmt":"2021-11-11T04:05:11","slug":"monitoring-redis-database-performance-with-new-relic","status":"publish","type":"post","link":"https:\/\/contentlab.com\/monitoring-redis-database-performance-with-new-relic\/","title":{"rendered":"Monitoring Redis Database Performance with New Relic"},"content":{"rendered":"

Redis<\/a> is a lightning-fast, distributed, in-memory key-value database. While Redis usually isn\u2019t used as a primary data store, it\u2019s often used as a fast cache in areas of applications where performance is paramount. As an in-memory key-value database<\/a>, Redis is much faster than traditional database systems. It\u2019s also commonly used as a lightweight distributed queue. You can use Redis\u2019s distributed pub\/sub feature to dispatch messages to various recipients without building the functionality yourself.<\/p>\n

Such use cases make Redis an integral part of any app it\u2019s built into, so it\u2019s important to ensure it has peak performance. Otherwise, your app performance will degrade, resulting in a poor user experience at best. At worst, your application will fail to work at all.<\/p>\n

Redis deployments can also be complicated, ranging from a single in-memory node to a multi-node cluster, or even hybrid in-memory\/on-disk deployments via Redis on Flash<\/a>. The more nodes in your Redis cluster, the more potential points of failure.<\/p>\n

Consequently, monitoring Redis is critical. And because Redis is used in so many different scenarios, making sure you\u2019re monitoring the right metrics for your use case is important. Ensuring Redis stays healthy helps create a top-notch user experience and alleviates the burden on transactional databases.<\/p>\n

Key Redis metrics<\/h3>\n

Since Redis-based application architectures can become quite complex, the components and data interactions involved produce many different metrics that you should monitor in real time. Not all metrics have the same weight, so let\u2019s examine some of the critical Redis metrics worth watching.<\/p>\n

Tip:<\/strong> To view all available metrics, check out our Redis integration docs<\/a> (which we\u2019ll walk through setting up below).<\/em><\/p>\n

Status metrics<\/h4>\n

software.uptimeMilliseconds<\/code>: Number of milliseconds since the Redis server starts. An unexpectedly low value here might mean Redis has recently crashed. You want to make sure the service is not restarting, so the higher uptime, the better.<\/p>\n

system.totalSystemMemoryBytes<\/code>: This is the amount of memory in bytes available in the instance where Redis is running. Monitoring this metric is important. If your Redis installation is not capable of scaling out and the host machine runs out of memory, the operating system may kill the Redis server process. You can improve the number by adding storage capacity to meet increased demands.<\/p>\n

Performance metrics<\/h4>\n

net.connectedClients<\/code>: This is the number of client connections (excluding connections from replicas). Since Redis is single-threaded, one process serves all client requests. If the number of connected clients grows, the server will spend less resource time processing each request, so clients will need to wait longer for responses. Monitoring the number of clients may also reveal applications that are creating unexpected client connections or failing to close them after use.<\/p>\n

net.commandsProcessedPerSecond<\/code>: Monitoring this metric is critical to ensure Redis is performing to a high standard. If you notice both a high latency connection and low throughput, you can investigate the causes of these problems, then identify and remove the root issues.<\/p>\n