转载

Cloud Insight 仪表盘上线 | 全面监控 Redis

OneAPM CI 探针仪表盘功能重磅上线，默认安装了探针，配置平台服务就会自动生成相应的仪表盘，而且仪表盘将包含所有数据。此外，本文也将重点介绍 Redis 的几项监控指标以及一些值得注意的部分，希望给使用 Redis 的读者带来一些帮助。

仪表盘

任意时间段数据查询

默认只能显示最近一小时的数据，而现在在仪表盘上可以选取固定时间段查看数据，7天内，15天之内，还可以自定义具体时间段，当然默认显示的是30分钟内的数据。 Cloud Insight 仪表盘上线 | 全面监控 Redis

数据筛选

随着现在业务的复杂，一个应用肯定会在多台服务器上部署，那就需要同时监控多台服务器，那如果只需要看某一台服务器的某项指标，仪表盘就派上用场啦！通常仪表盘数据是多个服务器数据的集合，如果想看单个服务器数据，可以根据主机名进行筛选。此外，里面还有多条筛选条件，例如 device url tag 等， Docker 可以选择 image 等。稍后我们会上线自定义仪表盘，通过 tag 标签轻松实现对数据的聚合、过滤、检索。 Cloud Insight 仪表盘上线 | 全面监控 Redis

Cloud Insight 仪表盘上线 | 全面监控 Redis

监控 Redis 指标

Cloud Insight 将监控 Redis 的以下指标

1  aof.last_rewrite_time      上次rewrite操作使用的时间(单位s)   2  aof.rewrite        rewrite 的次数   3  clients.biggest_input_buf     当前客户端连接的最大输入缓存   4  clients.blocked    被阻塞的客户端数   5  clients.longest_output_list   当前客户端连接的最大输出列表   6  cpu.sys       系统cpu   7  cpu.sys_children    后台进程的sys cpu使用率   8  cpu.user      redis server的user cpu使用率   9  cpu.user_children    后台进程的user cpu使用率   10 info.latency_ms    Redis 服务器响应延迟措施所花费的平均时间   11  keys.evicted  因为内存大小限制，而被驱逐出去的键的个数   12  keys.expired   自启动起过期的key的总数   13  mem.fragmentation_ratio      used_memory_rss/used_memory比例，一般情况下，used_memory_rss略高于used_memory，当内存碎片较多时，则mem_fragmentation_ratio会较大，可以反映内存碎片是否很多   14  mem.lua   lua引擎使用的内存   15  mem.peak   内存使用的峰值大小   16  mem.rss   系统给redis分配的内存（即常驻内存）   17  mem.used   使用内存，单位B   18  net.clients            连接的客户端数   19  net.commands     每秒运行命令数   20  net.rejected         因为最大客户端连接数限制，而导致被拒绝连接的个数   21  net.slaves            连接的从库数   22  perf.latest_fork_usec    上次的fork操作使用的时间（单位ms）   23  pubsub.channels      当前使用中的频道数量／ 发布/订阅频道数   24  pubsub.patterns       当前使用的模式的数量／ 发布/订阅模式数   25  rdb.bgsave          通过子进程来进行数据持久化   26  rdb.changes_since_last   自上次dump后rdb的改动   27  rdb.last_bgsave_time       上次save的时间戳   28  replication.master_repl_offs     全局的数据同步偏移量   29  stats.keyspace_hits      在main dictionary(todo)中成功查到的key个数   30  stats.keyspace_misses     在main dictionary(todo)中未查到的key的个数

对于上述各项 Redis 指标，在这篇文章中我们将重点介绍几项，分类如下：

性能指标内存指标基本活动指标持久性指标错误指标

性能指标

低错误率，良好的性能是系统健康的顶级指标之一。

指标：latency

latency 是一个客户端发送请求和实际的服务器响应之间的时间的指标。跟踪延迟是检测 Redis 性能变化的最直接的方式。由于 Redis 单线程的性质，所以延迟分布的异常值可能导致严重的瓶颈。因为一个请求的响应时间过长，就增加了所有后续请求的延迟。所以一旦确定有延迟的问题，你就要采取一些措施来诊断和解决性能问题。

指标：instantaneous ops per_sec

跟踪 Redis 实例命令处理的过程是诊断高延迟的关键。高延迟可能由以下问题引起，积压的命令队列，慢命令，网络连接超时等。你可以通过测量每秒处理的指令数来查看，如果它几乎保持恒定，那就不是计算密集型的命令造成的；如果是一个或多个缓慢的命令导致的延迟问题，你会看到你的每秒下降或跌落的命令数。

把每秒处理命令的下降的数量和历史数据相比，可以作为一个低命令量或慢命令阻塞系统的标志。低的命令量可能是正常的，也可能是上游的问题。

指标：hit rate

当使用 Redis 作为缓存时，监控缓存 hit rate 可以告诉你缓存使用是否有效。低命中率意味着客户正在寻找不存在的 key。Redis 不提供直接命中率指标，但我们可以这样计算它： Cloud Insight 仪表盘上线 | 全面监控 Redis

keyspace_misses 指标在错误指标部分讨论。

低命中率可能由多种因素引起，包括数据过期和 Redis 分配给的内存不足（这可造成 key 驱逐）。低命中率可能会导致你的应用程序延迟增加，因为他们必须从一个更慢的替代资源处获取数据。

内存指标

指标：used_memory

内存的使用是 Redis 性能的一个关键组成部分。如果 used_memory 超过总的系统可用内存，操作系统将开始交换旧的或未使用的部分内存。每一次把交换部分写入磁盘，都会严重影响性能。从磁盘读写的速度，达到5个数量级（100000x！），远比从内存读写慢（0.1µ的记忆与10毫秒磁盘)。

您可以配置 Redis ，限定一定的内存量。在 redis.conf 文件里面设置 maxmemory 指令，这样就可以直接控制 Redis 的内存使用量。maxmemory 配置一个驱逐政策确定 Redis 应该如何释放内存。

指标: mem fragmentation ratio

mem fragmentation ratio 指标表明了 Redis 给操作系统分配的内存使用率。

了解 mem fragmentation ratio 数据指标是了解你的 Redis 实例的性能的重要一步。fragmentation ratio 大于1表示碎片正在发生。超过1.5 表明过度分散，即你的 Redis 实例消耗了150%的物理内存；fragmentation ratio < 1 ,意味着 Redis 需求大于你系统可用的内存，从而导致交换。交换到磁盘将导致延迟增加显著。理想情况下，操作系统会在物理内存中分配一个连续的段，其碎片率等于1或稍大。

如果你的服务器 fragmentation ratio 在1.5以上，重新启动你的 Redis 实例将允许操作系统恢复以前由于破损而无法使用的内存。

当然，如果你的 Redis 服务器 fragmentation ratio 低于1，你可能需要快速增加可用内存或减少内存使用。

指标：evicted_keys (只限内存)

如果你是使用 Redis 作缓存，你可以配置它自动清除 keys 在其命中 maxmemory 限定后。如果你是使用 Redis 作为一个数据库或队列，你可能更喜欢交换驱逐，在这种情况下，你可以跳过这个指标。

跟踪删除 key 是很重要的，因为 Redis 按顺序处理每个操作，所以大量的 key 将会导致较低的命中率，从而延长等待时间。如果你使用的是 TTL，你可能不需要删除 key 。在这种情况下，如果这个指标始终高于零，你很可能会在实例中会看到延迟增加。大多数其他的配置不使用 TTL 最终会耗尽内存，并开始删除 key 。如果你能接受这个响应时间，那么相应的稳定的回收率也就可以接受了。

您可以通过命令行配置 key 过期策略：

redis-cli CONFIG SET maxmemory-policy <policy>

policy 位置，可以输入以下参数：

volatile-lru     删除最新使用的key之间的到期集   volatile-ttl     用最短的时间移除一个key，用一个过期集来存活   volatile-random  删除一个随机key之间的到期集。   allkeys-lru      从所有key的集合中删除最近使用的key   allkeys-random   从所有key的集合中移除一个随机key

指标：blocked_clients

Redis 提供了大量的阻塞命令来操作列表，BLPOP, BRPOP,和 BRPOPLPUSH 分别是 LPOP, RPOP, 和 RPOPLPUSH 的变种。当源列表是非空的，命令正常执行。而当源列表是空的的时候，阻塞命令将等待源被填充才会执行，或者达到一个超时时间才会执行。

阻塞的客户数量的增加可能是一个麻烦的迹象，延迟或其他问题会防止源列表被填充。虽然一个封闭的客户端本身是不会引起警报，但是如果你看到一个持续的非零的值，这个指标你就应该注意了。

基本活动指标

指标：connected_clients

通常访问 Redis 是由一个应用程序介入的（用户一般不直接访问数据库），大多数应用，将对连接的客户端的数量有合理的上限和下限。如果数值偏离正常范围内，就表明有问题。如果太低，上游连接可能已丢失，如果过高，大量的并发客户端连接可能会压倒你的服务器处理请求的能力。

无论如何，客户端连接的最大数值始终是由操作系统，Redis 的配置，和网络的局限性决定的。监控客户端连接帮助确保你有足够的可用资源用于新的客户端连接或管理会话。

指标：connected_slaves

如果你的数据库是只读的，繁重的，你很可能使用现有的 Redis 主从数据库复制功能。在这种情况下，监控连接从站的数量是很关键的。如果 slaves 连接改变和预计的不符，则说明可能主机 down 了或 slaves 实例有问题。 Cloud Insight 仪表盘上线 | 全面监控 Redis

指标：master last io seconds ago

当使用 Redis 的的复制功能时，slaves 实例定期检查与他们的 master 通信时间。没有通信的时间间隔很长，则问题可能出现在主 Redis 的服务器上，或在从服务器上，或介于两者之间。由于 Redis 执行同步的方式,会有运行 slaves 提供的旧数据风险，因此最大限度地减少主从通信中断是非常关键的。当从机连接到主机时，无论是否是首次或重新连接，它都会发送一个 SYNC 命令。SYNC 命令会使主器件立即开始一个后台进程来保存数据库到磁盘，同时缓冲所有新命令接收将修改数据集。数据被发送到客户端连同当背景保存完成缓冲的命令。每次从机执行同步，都可能会在 master 实例上导致显著延迟。

指标：keyspace

保持追踪数据库的 key 数量也是一个好主意。作为内存数据存储器，键空间越大，Redis 就需要越多的物理内存以确保最佳性能，这样 Redis 将继续增加 key ，直到它到达 maxmemory 限制，此时就会开始和增加 key 相同的速率删除 key ，这将出现一个「平行」图。

如果您正在使用 Redis 作为缓存，看看低命中率的图表，你客户端也许在请求旧的数据或被删除的数据。跟踪你的 keyspace_misses 的数量一段时间后会帮你查明原因。

另外，如果你使用 Redis 的数据库或队列，删除 key 可能不是一个好的选择。随着你的键值空间的增长，你可能需要考虑增加内存到你的机器或在主机之间来分割数据集。添加更多存储器是一种简单而有效的解决方案。当需要更多的资源而一个服务器不能提供时，你可以整合多台计算机来分区或分片存储数据。Redis 可以实现分区分片存储而不需要迁离或交换更多的键值。

指标：rdb last save time 和 rdb changes since last_save

通常情况下，它要留意你的数据集的波动。写入磁盘时过长的时间间隔可能会导致在服务器故障的情况下数据丢失。最后保存时间和故障时间之间的数据集所做的任何更改将丢失。监测 rdb changes since last save 让你更深入地了解你的数据的波动性。如果你的数据集在一段区间内并没有太大的改变，那么写入磁盘时过长的时间间隔就不是一个问题。跟踪这两个指标，在给定时间点可以了解有多少数据已经丢失。

错误指标

指标：rejected_connections

Redis 能够处理多个活动连接，默认可与10000可用的客户端连接，你可以设置不同的最大连接数，通过执行 redis.conf 的 maxclient 的指令。如果你的 Redis 的实例已经是最大连接数，那么任何新的连接尝试都会被断开。

Cloud Insight 仪表盘上线 | 全面监控 Redis

注意，您的系统可能不支持您请求的 maxclient 指令的连接数量。Redis 检查内核，以确定可用的文件描述符的数量。如果可用的文件描述符的数量小于maxclient+32（Redis 的保留32文件描述符供自己使用），则该 maxclient 的指令被忽略并可用文件描述符的数量被使用。

请参阅有关 redis.io 的文档上 Redis 如何处理客户端连接的详细信息。

指标：keyspace_misses

每次 Redis 查找 key，只有两种可能的结果：该键值存在，或者该键值不存在。找了一个不存在的 key 会导致 keyspace misses 递增。如果该指标一直是非零值，意味着客户端试图查找数据库的键不存在。如果您不使用 Redis 作为缓存，keyspace misses 应达到或接近零。需要注意的是任何一个阻塞操作（BLPOP，BRPOP 和 BRPOPLPUSH ）的空键响应将导致 keyspace_misses 增加。