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

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 官方博客。