OneAPM作为应用性能领域的新兴领军企业，近日发布了重量级新产品——CloudInsight数据管理平台，用它还能监控所有基础组件，并通过tag标签对数据进行管理。
日前，CloudInsight(Ci)探针仪表盘功能重磅上线，默认安装了探针，配置平台服务都会手动生成相应的仪表盘，但是仪表盘将包含所有数据。据悉，本文也将重点介绍Redis的几项监控指标以及一些值得注意的部份，希望给使用Redis的读者带来一些帮助。
仪表盘
任意时间段数据查询
默认只能显示近来一小时的数据，而如今在仪表盘上可以选定固定时间段查看数据，7天内，15天之内，还可以自定义具体时间段，其实默认显示的是30分钟内的数据。
数据筛选
随着现今业务的复杂，一个应用肯定会在多台服务器上布署，那就须要同时监控多台服务器，那若果只须要看某一台服务器的某项指标，仪表盘就派上用场啦！一般仪表盘数据是多个服务器数据的集合，假如想看单个服务器数据，可以按照主机名进行筛选。据悉，上面还有多条筛选条件，比如deviceurltag等，Docker可以选择image等。稍后我们会上线自定义仪表盘，通过tag标签轻松实现对数据的聚合、过滤、检索。
监控Redis指标
CloudInsight将监控Redis的以下指标
1aof。last_rewrite_time先前rewrite操作使用的时间(单位s)2aof。rewriterewrite的次数3clients。biggest_input_buf当前顾客端联接的最大输入缓存4clients。blocked被阻塞的顾客端数5clients。longest_output_list当前顾客端联接的最大输出列表6cpu。sys系统cpu7cpu。sys_children后台进程的syscpu使用率8cpu。userredisserver的usercpu使用率9cpu。user_children后台进程的usercpu使用率10info。latency_msRedis服务器响应延后举措所耗费的平均时间11keys。evicted由于显存大小限制，而被驱逐出去的键的个数12keys。expired自启动起过期的key的总量13mem。fragmentation_ratioused_memory_rss/used_memory比列，通常情况下，used_memory_rss略低于used_memory，当显存碎片较多时，则mem_fragmentation_ratio会较大，可以反映显存碎片是否好多14mem。
lualua引擎使用的显存15mem。peak显存使用的峰值大小16mem。rss系统给redis分配的显存（即常驻显存）17mem。used使用显存，单位B18net。clients联接的顾客端数19net。commands每秒运行命令数20net。rejected由于最大顾客端联接数限制，而造成被拒绝联接的个数21net。slaves联接的从库数22perf。latest_fork_usec先前的fork操作使用的时间（单位ms）23pubsub。channels当前使用中的频道数目／发布/订阅频道数24pubsub。patterns当前使用的模式的数目／发布/订阅模式数25rdb。bgsave通过子进程来进行数据持久化26rdb。changes_since_last自先前dump后rdb的改动27rdb。last_bgsave_time先前save的时间戳28replication。master_repl_offs全局的数据同步偏斜量29stats。keyspace_hits在maindictionary(todo)中成功查到的key个数30stats。keyspace_misses在maindictionary(todo)中未查到的key的个数
对于上述各项Redis指标，在这篇文章中我们将重点介绍几项，分类如下：
性能指标显存指标基本活动指标持久性指标错误指标
性能指标
低错误率，良好的性能是系统健康的顶尖指标之一。
指标：latency
latency是一个顾客端发送恳求和实际的服务器响应之间的时间的指标。跟踪延后是测量Redis性能变化的最直接的方法。因为Redis单线程的性质，所以延后分布的异常值可能造成严重的困局。由于一个恳求的响应时间过长，就降低了所有后续恳求的延后。所以一旦确定有延后的问题，你就要采取一些举措来确诊和解决性能问题。
指标：instantaneousopsper_sec
跟踪Redis实例命令处理的过程是确诊高延后的关键。高延后可能由以下问题造成，积压的命令队列，慢命令，网路联接超时等。你可以通过检测每秒处理的指令数来查看，假若它几乎保持恒定，那就不是估算密集型的命令引起的；若果是一个或多个平缓的命令引起的延后问题linux系统介绍，你会听到你的每秒下降或跌落的命令数。
把每秒处理命令的增长的数目和历史数据相比，可以作为一个低命令量或慢命令阻塞系统的标志。低的命令量可能是正常的，也可能是上游的问题。
指标：hitrate
当使用Redis作为缓存时，监控缓存hitrate可以告诉你缓存使用是否有效。低命中率意味着顾客正在找寻不存在的key。Redis不提供直接命中率指标，但我们可以这样估算它：
keyspace_misses指标在错误指标部份讨论。
低命中率可能由多种诱因造成，包括数据过期和Redis分配给的显存不足（这可导致key驱逐）。低命中率可能会造成你的应用程序延后降低，由于她们必须从一个更慢的取代资源处获取数据。
显存指标
指标：used_memory
显存的使用是Redis性能的一个关键组成部份。假如used_memory超过总的系统可用显存，操作系统将开始交换旧的或未使用的部份显存。每一次把交换部份写入c盘，就会严重影响性能。从c盘读写的速率，达到5个数目级（100000x！），远比从显存读写慢（0.1µ的记忆与10微秒c盘)。
您可以配置Redis，限定一定的显存量。在redis.conf文件上面设置maxmemory指令，这样就可以直接控制Redis的显存使用量。maxmemory配置一个驱逐新政确定Redis应当怎样释放显存。
指标:memfragmentationratio
memfragmentationratio指标表明了Redis给操作系统分配的显存使用率。
了解memfragmentationratio数据指标是了解你的Redis实例的性能的重要一步。fragmentationratio小于1表示碎片正在发生。超过1.5表明过度分散，即你的Redis实例消耗了150%的化学显存；fragmentationratio<1,意味着Redis需求小于你系统可用的显存，因而造成交换。交换到c盘将造成延后降低明显。理想情况下，操作系统会在化学显存中分配一个连续的段，其碎片率等于1或稍大。
假如你的服务器fragmentationratio在1.5以上，重新启动你的Redis实例将容许操作系统恢复原先因为损坏而未能使用的显存。
其实，假如你的Redis服务器fragmentationratio高于1，你可能须要快速降低可用显存或降低显存使用。
指标：evicted_keys(只限显存)
假如你是使用Redis作缓存，你可以配置它手动消除keys在其命中maxmemory限定后。假如你是使用Redis作为一个数据库或队列，你可能更喜欢交换驱逐，在这些情况下，你可以跳过这个指标。
跟踪删掉key是很重要的，由于Redis按次序处理每位操作，所以大量的key将会造成较低的命中率，进而延长等待时间。假如你使用的是TTL，你可能不须要删掉key。在这些情况下，假如这个指标一直低于零，你很可能会在实例中会看见延后降低。大多数其他的配置不使用TTL最终会用尽显存，并开始删掉key。假如你能接受这个响应时间，这么相应的稳定的回产率也就可以接受了。
您可以通过命令行配置key过期策略：
redis-cliCONFIGSETmaxmemory-policy
policy位置，可以输入以下参数：
volatile-lru删掉最新使用的key之间的到期集volatile-ttl用最短的时间移除一个key，用一个过期集来存活volatile-random删掉一个随机key之间的到期集。allkeys-lru从所有key的集合中删掉近来使用的keyallkeys-random从所有key的集合中移除一个随机key
指标：blocked_clients
Redis提供了大量的阻塞命令来操作列表，BLPOP,BRPOP,和BRPOPLPUSH分别是LPOP,RPOP,和RPOPLPUSH的变种。当源列表是非空的，命令正常执行。而当源列表是空的的时侯，阻塞命令将等待源被填充才能执行，或则达到一个超时时间才能执行。
阻塞的顾客数目的降低可能是一个麻烦的征兆，延后或其他问题会避免源列表被填充。其实一个封闭的顾客端本身是不会造成警报，并且假如你看见一个持续的非零的值，这个指标你就应当注意了。
基本活动指标
指标：connected_clients
一般访问Redis是由一个应用程序介入的（用户通常不直接访问数据库），大多数应用，将对联接的顾客端的数目有合理的上限和下限。假如数值偏离正常范围内，就表明有问题。假如太低，上游联接可能已遗失，假如偏低，大量的并发顾客端联接可能会压倒你的服务器处理恳求的能力。
无论怎样，顾客端联接的最大数值仍然是由操作系统，Redis的配置，和网路的局限性决定的。监控顾客端联接帮助确保你有足够的可用资源用于新的顾客端联接或管理会话。
指标：connected_slaves
假如你的数据库是只读的，艰巨的，你很可能使用现有的Redis主从数据库复制功能。在这些情况下，监控联接从站的数目是很关键的。假如slaves联接改变和预计的不符，则说明可能主机down了或slaves实例有问题。
指标：masterlastiosecondsago
当使用Redis的的复制功能时，slaves实例定期检测与她们的master通讯时间。没有通讯的时间间隔很长，则问题可能出现在主Redis的服务器上，或在从服务器上，或介于二者之间。因为Redis执行同步的方法,会有运行slaves提供的旧数据风险，因而最大限度地降低主从通讯中断是十分关键的。当从机联接到主机时，无论是否是首次或重新联接，它就会发送一个SYNC命令。SYNC命令会使主元件立刻开始一个后台进程来保存数据库到c盘，同时缓冲所有新命令接收将更改数据集。数据被发送到顾客端连同当背景保存完成缓冲的命令。每次从机执行同步，都可能会在master实例上造成明显延后。
指标：keyspace
保持追踪数据库的key数目也是一个好主意。作为显存数据储存器，键空间越大，Redis就须要越多的化学显存以确保最佳性能，这样Redis将继续降低key，直至它抵达maxmemory限制，此时才会开始和降低key相同的速度删掉key，这将出现一个「平行」图。
假如您正在使用Redis作为缓存，瞧瞧低命中率的图表，你顾客端其实在恳求旧的数据或被删掉的数据。跟踪你的keyspace_misses的数目一段时间后会帮你查明缘由。
另外红帽查看cpu，假如你使用Redis的数据库或队列，删掉key可能不是一个好的选择。随着你的通配符空间的下降，你可能须要考虑降低显存到你的机器或在主机之间来分割数据集。添加更多储存器是一种简单而有效的解决方案。当须要更多的资源而一个服务器不能提供时，你可以整合多台计算机来分区或分片储存数据。Redis可以实现分区分片储存而不须要迁离或交换更多的通配符。
指标：rdblastsavetime和rdbchangessincelast_save
一般情况下，它要留心你的数据集的波动。写入c盘时过长的时间间隔可能会造成在服务器故障的情况下数据遗失。最后保存时间和故障时间之间的数据集所做的任何修改将遗失。检测rdbchangessincelastsave让你更深入地了解你的数据的波动性。假如你的数据集在一段区间内并没有太大的改变，这么写入c盘时过长的时间间隔就不是一个问题。跟踪这两个指标，在给定时间点可以了解有多少数据早已遗失。
错误指标
指标：rejected_connections
Redis才能处理多个活动联接，默认可与10000可用的顾客端联接，你可以设置不同的最大联接数，通过执行redis.conf的maxclient的指令。假如你的Redis的实例早已是最大联接数，这么任何新的联接尝试就会被断掉。
注意，您的系统可能不支持您恳求的maxclient指令的联接数目。Redis检测内核，以确定可用的文件描述符的数目。假如可用的文件描述符的数目大于maxclient+32（Redis的保留32文件描述符供自己使用），则该maxclient的指令被忽视并可用文件描述符的数目被使用。
请参阅有关redis.io的文档上Redis怎样处理顾客端联接的详尽信息。
指标：keyspace_misses
每次Redis查找key，只有两种可能的结果：该通配符存在，或则该通配符不存在。找了一个不存在的key会造成keyspacemisses递增。假如该指标始终是非零位，意味着顾客端企图查找数据库的键不存在。假如您不使用Redis作为缓存，keyspacemisses应达到或接近零。须要注意的是任何一个阻塞操作（BLPOP，BRPOP和BRPOPLPUSH）的空键响应将造成keyspace_misses降低。
安装监控Redis
安装探针，配置Redis
说了这么多的干货，是时侯安装CloudInsight瞧瞧具体能显示出哪些东东来了，首先是一键安装，直接在服务器命令行复制就好。
默认应用的名称是主机名，也可以自己在/etc/oneapm-ci-agent/oneapm-ci-agent.conf上面进行配置。
然后在web端就有这个主机应用的数据啦。
安装好平台监控，接出来就是实现Redis监控啦，只须要通过简单配置，复制redis.yaml.example模版，更改右图，密码tag等以后重启探针，就可以看到Redis的性能监控的具体数据啦。
更改完配置文件，重启探针，此时就完成了对Redis的监控linux qq，如今瞧瞧具体的数据指标，了解Redis的健康情况。
图中显示的指标就是本文开头介绍的各项指标，针对部份指标，本文也做了相应的说明。
下一个功能，等您来照亮！
目前，CloudInsight可以监控Ubuntu、MacOSX、Fedora、CentOS和RedHat的主机监控。
在平台服务支持上，CloudInsight早已支持ActiveMQApacheApacheTomcatApacheKafkaCassandraCouchbaseCouchDBDockerElasticSearchMemcachedMongoDBMySQLNginxPostgreSQLPHP-FPMRedisRabbitMQ17种服务红帽查看cpu，其中涉及的Docker，PHP-FPM都是在用户提的需求中提早降低支持的，因而我们欢迎您和我们一起构建更完美的数据管理平台，期盼您的参与！
