OneAPM 作为应用性能领域的新兴领军企业，近期发布了重量级新产品—— Cloud Insight 数据管理平台，用它能够监控所有基础组件，并通过 tag 标签对数据进行管理。
近日，Cloud Insight (Ci) 探针仪表盘功能重磅上线，默认安装了探针，配置平台服务就会自动生成相应的仪表盘，而且仪表盘将包含所有数据。此外，本文也将重点介绍 Redis 的几项监控指标以及一些值得注意的部分，希望给使用 Redis 的读者带来一些帮助。
仪表盘
任意时间段数据查询
默认只能显示最近一小时的数据，而现在在仪表盘上可以选取固定时间段查看数据，7天内，15天之内，还可以自定义具体时间段，当然默认显示的是30分钟内的数据。
数据筛选
随着现在业务的复杂，一个应用肯定会在多台服务器上部署，那就需要同时监控多台服务器，那如果只需要看某一台服务器的某项指标，仪表盘就派上用场啦！通常仪表盘数据是多个服务器数据的集合，如果想看单个服务器数据，可以根据主机名进行筛选。此外，里面还有多条筛选条件，例如 device url tag 等， Docker 可以选择 image 等。稍后我们会上线自定义仪表盘，通过 tag 标签轻松实现对数据的聚合、过滤、检索。
监控 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 不提供直接命中率指标，但我们可以这样计算它：
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 实例有问题。
指标：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 的实例已经是最大连接数，那么任何新的连接尝试都会被断开。
注意，您的系统可能不支持您请求的 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 增加。
安装监控 Redis
安装探针，配置 Redis
说了那么多的干货，是时候安装 Cloud Insight 看看具体能显示出什么东东来了，首先是一键安装，直接在服务器命令行复制就好。
默认应用的名称是主机名，也可以自己在/etc/oneapm-ci-agent/oneapm-ci-agent.conf 里面进行配置。
之后在 web 端就有这个主机应用的数据啦。
安装好平台监控，接下来就是实现 Redis 监控啦，只需要通过简单配置，复制redis.yaml.example 模版，修改下图，密码 tag 等之后重启探针，就可以看见 Redis 的性能监控的具体数据啦。
修改完配置文件，重启探针，此时就完成了对 Redis 的监控，现在看看具体的数据指标，了解 Redis 的健康情况。
图中显示的指标就是本文开头介绍的各项指标，针对部分指标，本文也做了相应的说明。
下一个功能，等您来点亮！
目前，Cloud Insight 可以监控 Ubuntu、Mac OS X、Fedora、CentOS 和 RedHat 的主机监控。
在平台服务支持上，Cloud Insight 已经支持 ActiveMQ Apache Apache Tomcat Apache Kafka Cassandra Couchbase CouchDB Docker Elastic Search Memcached MongoDB MySQL Nginx PostgreSQL PHP-FPM Redis RabbitMQ 17种服务，其中涉及的 Docker，PHP-FPM 都是在用户提的需求中提前增加支持的，因此我们欢迎您和我们一起打造更完美的数据管理平台，期待您的参与！
本文系 OneAPM 工程师编译整理。OneAPM 是应用性能管理领域的新兴领军企业，Cloud Insight 能帮助企业用户和开发者轻松实现：监控各项基础组件以及对数据进行聚合、过滤和筛选的功能，致力于打造一个更为强大的数据管理平台。想阅读更多技术文章，请访问 OneAPM 官方博客。
