李萌，数据技术专家，Elastic-Stack产品深度用户，ES认证工程师。对Elastic-Stack的开发、架构、运维有深入的经验；实践过各种ES项目，最暴力的大数据分析应用，最复杂的业务系统应用。前言图：Redis流行度排行榜Redis无论是在业务应用系统还是在大数据领域都非常流行和好用；但是Redis也很脆弱，不好用，问题多多。2012年之前是基于memcached，后来转战Redis阵营。我体验过单实例模式，主从模式，哨兵模式，代理模式，集群模式。很少在真正的公司层面使用，我对Redis的掌握很好。片面性导致实际项目中存在很多问题。想要用好Redis，需要整体掌握三个层次：开发层次架构层次运维层次其中，架构和运维非常重要。大多数中小企业在开发层面只满足通用功能，数据规模稍大，业务复杂。度数高了，就容易出现各种架构和运维问题。本文的主要目的是讨论Redis监控系统。当然，目前行业内成熟的产品很多，但个人感觉还是很常规的。他们只做一些粗粒度的监控，并没有根据业务需求的特点进行细化，从而提供逆向架构开发。优化。本文内容将讨论以下问题：Redis监控系统包括哪些方面？Redis监控系统的搭建我们做了哪些工作？Redis监控系统应该细化到什么程度？为什么要用ELK搭建监控系统？需求背景项目描述公司业务范围属于车联网行业，拥有百万真实车主用户。业务项目围绕车主生活服务展开。为了提高系统性能，引入Redis作为缓存中间件。具体描述如下：部署架构采用Redis-Cluster模式；后台应用系统数十个，应用实例数超过200个；所有应用系统共享一组缓存集群；集群节点数几十个，节点数翻倍，增加了容灾和备份环境；集群节点的内存配置比较高。图解：Redis集群架构及应用架构示意图问题描述系统启动之初，Redis一切正常。随着接入的应用系统越来越多，接入的应用系统子模块也越来越多，开始出现一些问题，应用系统有感知，集群服务器也有感知，如下所述：集群节点崩溃；集群节点冻结；一些后端应用程序访问集群非常慢。其实问题的根源在于架构运维的缺失。Redis集群服务器的运行监控其实很容易做到。也提供了很多直接的命令方式，但是只能看到服务器上的一些常用指标信息，无法深入分析。对Redis的内部运行一无所知，尤其是业务应用如何使用Redis集群：Redis集群使用有多流行？哪些应用占用Redis内存资源较多？哪些应用占用Redis访问量最高？哪些应用不合理地使用Redis类型？使用Redis资源分配的应用系统模块如何？使用Redis集群的应用有哪些热点问题？监控系统监控的目的不仅仅是为了监控Redis本身，而是为了更好的利用Redis。传统的监控一般比较简单，没有系统性，但是对于Redis，我个人认为至少包括：一是服务端，二是应用，三是服务端和应用的联合分析。服务器：服务器首先是操作系统层面，常用的CPU、内存、网络IO、磁盘IO、服务器上运行的进程信息等；Redis运行进程信息，包括服务器运行信息、客户端连接数、内存消耗、Persistence信息、key值个数、主从同步、命令统计、集群信息等；Redis操作日志，会记录一些重要的操作过程。例如，在运行持久化时，可以有效帮助分析崩溃和卡顿的程序。应用端：应用端，获取应用端使用Redis的一些行为，具体哪些应用和模块占用Redis资源最多，哪些应用和模块消耗Redis资源最多，哪些应用和哪些模块使用不正确等。联合分析：结合服务器的运行和应用的行为进行联合分析，如：服务器突然阻塞的某些原因可能是应用设置了较大的缓存键值，或者使用的键值列表，数据量过大导致阻塞。为什么选择Elastic-Stack技术栈作为解决方案？大多数第三方只监控一些指标，ELK（Elasticsearch、Logstash、Kibana）仍然用于详细日志。也就是说，使用了第三方监控指标后，还得再建一个ELK集群才能看到详细的日志。然后说一下Elastic-Stack技术栈集成的优势。指标和日志文件也可用。从开始的采集到入库到最后的报表面板，集成的很好，门槛很低。下面详细说说我们是怎么做的，做了哪些工作。服务器系统Elastic-Stack家族有Metricbeat产品，支持系统层面的信息采集。简单配置即可启动Elastic集群地址和系统指标模块，在Kibana中创建已有的系统监控面板非常简单快捷，一般运维即可。图解：metcibeat示意图系统指标信息采集示例配置如下：服务器集群采集Redis集群的运行信息。业界通常的做法是使用Redis提供的info命令定时采集。info获取的信息包括以下内容：server：Redis服务器的一般信息clients：客户端的连接部分memory：内存消耗相关信息persistence：RDB和AOF相关信息stats：一般统计replication：master/slave复制信息cpu:CPU消耗统计commandstats:Redis命令统计cluster:Redis集群信息keyspace:数据库相关统计Elastic-Stack家族的Metricbeat产品也支持Redis模块，同样是使用info命令获取，但是有一些实现局限性，如下所述：Redis集群Metricbeats无法表达主从关系信息；Redis集群的一些统计信息会一直累加的增加，比如命令数，如果想得到命令数的峰值是拿不到的；Metricbeats不能动态改变Redis集群的状态信息，比如集群新增节点、离线节点等。所以这里参考CacheCloud产品（搜狐团队开源）。我们定制设计开发了一个Agent，定时从Redis集群收集信息，并在内部做一些简单的统计值计算，转换成Json，写入本地文件，通过Logstash收集发送到Elasticsearch.图解：Redis服务器运行信息采集架构示意图。服务器日志Redis服务器运行日志收集很简单，直接通过Elastic-Stack家族的Filebeat产品，里面包含Redis模块，配置Elastic服务器，以及日志文件地址。图解：服务器日志采集流程Redis操作日志采集配置：应用端应用端信息采集是整个Redis监控系统中最重要的部分，也是实现起来最麻烦，链路最长的部分。首先是修改jedis(technicalstackJava)源码，添加内嵌代码，重新编译并引用到应用工程中，应用端对Redis集群的任何命令操作都会被捕获，并记录关键信息，然后写入本地文件。图：Redis应用端行为采集架构图应用端采集的数据格式如下：图：应用端采集的数据。Jedis修改：jedis修改记录的信息如下：r_host：访问Redis集群的服务器地址和端口。一个ip：端口；r_cmd：执行命令类型，如get、set、hget、hset等；r_start：执行命令开始时间；r_cost：耗时；r_size：获取键值大小或设置键值大小；r_key：获取键值的名称；r_keys：键值的二次拆分，数组长度不限。这里需要强调一下，所有的应用系统共享一套集群，所以应用系统的键值是标准化的，按照特殊符号划分，比如：“应用名称_系统模块_动态变量_xxx”，主要是方便我们区分.jedis改造有几个地方，如下：类Connection.java文件，统计开始，记录命令执行开始时间；统计结束，记录命令结束时间、耗时等，并写入日志流；classJedisClusterCommand文件，获取key所在的地方key，方便后面分析applicationkey的行为。类Connection.java文件中有2个地方：图：类Connection.java文件中埋代码的地方图：类Connection.java文件中埋代码的地方有1个地方classJedisClusterCommandfile.javafile:图：类JedisClusterCommand文件埋点代码logback修改：应用端使用logback写入日志文件。同时为了更加准确，应用端在写日志的时候需要获取应用端的一些信息，如下：app_ip：应用端部署在服务器上的IP地址；app_host：服务器上部署应用程序的服务器名称。自定义一个Layout自动获取应用端的IP地址和服务器名：图：自定义Logback的Layoutapp配置：app配置是最后的收尾工作，主要是输出埋点日志数据，配置日志logback.xml文件即可：图：配置应用端日志文件logback.xml日志采集：应用端日志采集使用Logstash，配置日志目录，指向Elastic集群，这样整体监控日志采集部分就结束了。日志分析Redis服务器的日志分析比较简单，只是一些常规的指标。创建关键图表后，很容易看出问题。专注于应用端的日志分析。图：应用端使用Redis行为图表上线ELK监控系统后，我们观察分析了两周，得到了一些监控结果，如：应用端部分key值过大，超过1MB.这种key-value访问一次消耗时间过长，会严重造成拥塞；一些应用程序实际上使用Redis作为数据库；有的使用List类型作为消息队列，一次访问几十万条数据；半数以上;还有很多，就不一一介绍了。后续计划监控系统相当于架构师的眼睛。有了这个，就可以很容易的制定出Redis的优化改造方案：应用端和误用要改；server端要根据应用数据拆分，拆分出一些专用的集群，具体针对一些应用或者场景；开发者，如果以后有新的业务模块需要接入Redis，需要通知架构师审核。结束语监控系统项目历时数月，服务器端部分在短时间内完成，应用端随着应用的发布逐步完成。上线完成后，经过数周的后续分析，确定了整体优化方案。监控系统本身不是为了监控，而是为了提前发现问题，预见问题，最终解决问题。如果监控做得好，人们可以提前下班。Redis集群是个好东西，但是要完全掌握还需要很长时间，尤其是在架构和运维层面。如果没有，请做好监控。本文转载自微信公众号“DBAplus社区”，可通过以下二维码关注。转载本文请联系DBAplus社区公众号。
