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