我为何用 ElasticSearch 做 Redis 监控?

　　本文按照李猛老师在〖deeplus直播第220期〗线上分享讲演内容整理而成。（文末有获取本期PPT&回放的途径，不要错过）

　　

　　李猛

　　数据技术专家

　　序言

　　

　　图示：Redis热度排行

　　Redis当下挺流行，也挺好用，无论是在业务应用系统，还是在大数据领域都有重要的地位；但Redis也太脆弱，用不好，问题多多。2012年以前都是以memcached为主，之后转入Redis阵营，经历过单实例模式、主从模式、哨兵模式、代理模式，集群模式，真正公司层面用得好的极少，对于Redis掌控都太片面，导致实际项目中问题不少。

　　Redis要想用得好，需要整体把握3个层面：

　　其中构架与运维至关重要，多数中小型企业仅在开发层面满足常用功能，数据规模稍为大些，业务复杂度高些，就容易出现各类构架与运维问题。本文主旨是阐述Redis监控体系，目前业界其实也有好多成熟的产品，但个人感觉都太常规，只做到一些粗细度的监控， 没有根据业务需求特性因地制宜去细化，从而反向的提供构架开发优化方案。

　　本文内容将围绕如下几个问题展开讨论：

　　需求背景

　　项目描述

　　公司业务范围属于车联网行业，有上百万级的真实车主用户，业务项目围绕车主生活服务展开，为了提升系统性能，引入了Redis作为缓存中间件，具体描述如下：

　　

　　图示：Redis集群构架与应用构架*敏*感*词*

　　问题描述

　　系统刚开始关于Redis的一切都很正常，随着应用系统接入越来越多，应用系统子模块接入也越来越多，开始出现一些问题，应用系统有感知，集群服务端也有感知，如下描述：

　　其实问题的症结都是构架运维层面的缺乏，对于Redis集群服务端的运行监控虽然挺好做，本身也提供了好多直接的命令形式，但只能看见服务端的一些常用指标信息，无法深入剖析，治标不治本，对于Redis的内部运行一无所知，特别是对于业务应用怎样使用Redis集群一无所知：

　　监控体系

　　监控的目的不仅仅是监控Redis本身，而是为了更好的使用Redis。传统的监控通常比较单一化，没有系统化，但对于Redis来说，个人觉得起码包括：一是服务端，二是应用端，三是服务端与应用端联合剖析。

　　服务端：

　　应用端：

　　应用端、获取应用端使用Redis的一些行为，具体什么应用什么模块最占用 Redis资源、哪些应用什么模块最消耗Redis资源、哪些应用什么模块用法有误等。

　　联合剖析：

　　联合剖析结合服务端的运行与应用端使用的行为，如：一些导致服务端忽然阻塞的缘由，可能是应用端设置了一个很大的缓存通配符，或者使用的通配符列表，数据量超大导致阻塞。

　　解决方案

　　为什么会选择Elastic-Stack技术栈呢？

　　多数的第三方只监控一些指标，对于明细日志还是采用ELK（Elasticsearch、Logstash、Kibana），也就是说用第三方监控指标以后，还得再搭建一个ELK集群看明细日志。

　　再就是说Elastic-Stack技术栈整合的优势，指标也可以、日志文件也可以，从采集开始到储存、到最终报表面板都整合得非常好，门槛太低。

　　下面详尽谈谈我们具体如何做的，做了什么工作？

　　服务端系统

　　Elastic-Stack家族有Metricbeat产品，支持系统层面的信息搜集，简单的配置下Elastic集群地址和系统指标模块即可上线，并且会在Kibana中创建已有的系统监控面板，非常简单快速，一般运维就可以搞定。

　　

　　图示：metrcibeat*敏*感*词*

　　系统指标信息搜集配置样例如下：

　　服务端集群

　　采集Redis集群运行信息，业界一般做法都是采用Redis提供的info命令，定期搜集。

　　info获取的信息包括如下：

　　Elastic-Stack家族的Metricbeat产品也支持Redis模块，也是采用info命令获取的，但是有一些实现的局限性，如下描述：

　　所以这儿参考了CacheCloud产品（搜狐团队开源），我们自定义设计开发了 Agent，定时从Redis集群采集信息，并在内部做一些统计数值的简单估算，转换成Json，写入到本地文件，通过Logstash采集发送到Elasticsearch。

　　

　　图示：Redis服务端运行信息采集架构*敏*感*词*

　　服务端日志

　　Redis服务端运行日志采集很简单，直接通过Elastic-Stack家族的Filebeat产品，其中有Redis模块，配置一下Elastic服务端，日志文件地址即可。

　　

　　图示：服务端日志采集过程

　　Redis运行日志采集配置：

　　

　　应用端

　　应用端信息采集是整个Redis监控体系最重要的部份，也是实现最麻烦、链路最长的。首先是更改jedis（技术栈Java）源码，增加埋点代码，重新编译并引用到应用项目中，应用端对于Redis集群的任何命令操作，都会被捕捉，并记录下关键信息，之后写入到本地文件。

　　

　　图示：Redis应用端行为采集架构图

　　应用端采集的数据格式如下：

　　图示：应用端采集的数据案例

　　jedis更改：

　　jedis整修记录的信息如下：

　　在jedis整修有几处地方，如下：

　　在类Connection.java文件中有2处：

　　

　　图示：类Connection.java文件埋点代码的地方

　　

　　图示：类Connection.java文件埋点代码的地方

　　类JedisClusterCommand文件埋点代码.java文件中有1处：

　　

　　图示：类JedisClusterCommand文件埋点代码

　　logback更改：

　　应用端就会使用logback写入日志文件，同时为了愈发精准，应用端写入日志时还须要获取应用端的一些信息，如下：

　　自定义一个Layout，自动获取应用端的IP地址与服务器名称：

　　

　　图示：自定义Logback的Layout

　　app配置：

　　app配置属于最后扫尾工作，主要是输出埋点的日志数据，配置日志logback.xml文件即可：

　　

　　图示：配置应用端日志文件logback.xml

　　日志采集：

　　应用端日志采集采用Logstash，配置日志目录，指向Elastic集群，这样整体的监控日志采集部分就结束了。

　　日志剖析

　　Redis服务端的日志剖析比较简单，常规的一些指标而已，创建好关键的图表，容易看出问题。重点讨论应用端的日志剖析。

　　

　　图示：应用端使用Redis一些行为图表

　　ELK监控体系上线以后，我们连续观察剖析两周，获得了一些监控成果，如：

　　后续方案

　　监控体系相当于架构师的双眼，有了这个，Redis方面的优化整修方案就挺好制订了：

　　结语

　　监控体系项目前后经历过几个月，服务端部份短期内就完成的，应用端是随着应用发布逐渐完成的。上线完成以后又经历几周的跟踪剖析，才确定出来整体的优化方案。

　　监控体系本身并不是为了监控，而是发觉问题、预见问题，最终提早解决问题，监控做得好，下班下得早。

　　Redis集群是个好东西，完全把握还是须要太长的时间，特别是构架、运维层面，如果没有，请做好监控。

　　> > > >

　　Q&A

　　Q1：请问单台机器通常布署几个Redis实例呢？

　　A：依据服务器资源设置：

　　1、CPU核数，Redis是单线程工作模型，实际运行并非进程只有一个线程，这个要搞清楚；

　　2、内存，一个Redis进程配置部份显存，需要起码对等的显存闲置，fork子进程使用， 所以配置多实例要简单估算下；

　　3、网络，网络IO超过网卡限制，会出问题。

　　Q2：直播中提到的大key，hash要改成哪些？分片吗？

　　A：1、比如，一个面包车的基本信息，包括好多区块部份，用hash确实非常好理解，但是过期以后整个hash都删掉了，其实好多信息是固定的，不用定时过期的；2、拆分成小的string更合适。

　　Q3：在客户端复印key和value，如果是bigkey的话，qps有个1000，打印日志就占用很高的机器负载了吧？

　　A：1、打印的key，不包括value值内容，只有key以及value的大小；2、logback这种框架似乎支持的性能相当不错的，可以配置成异步的形式，如果还不够，可以直接输出到Kafka队列等。

　　Q4：请问ES如何布署MongoDB慢查询报表平台呢？

　　A：1、没有深度使用过MongoDB；2、基于Elastic-Stack做慢查询报表平台思路与Redis一样的，不管哪些指标+日志全部都采集到ES完事。

　　Q5：info all执行频繁，会时常阻塞服务器，怎么平衡它的性能呢？

　　A：1、因为采集的是服务端运行的快照信息，定时采集，可以设定时间间隔大一些，比如5s；2、执行info all，是在 java客户端，可以更改jedis，在其中捕获info命令，采集数据，观察剖析一段时间。

　　Q6：请问应用端jedis要如何埋点呢？

　　A：1、原有jedis版本基于2.9，在2个类中更改埋点，参考了CacheCloud产品。最新版本的程序近来没有关注，思路一样；2、详细见本文中贴出的代码。

　　Q7：监控的话，个人认为置于K8S上面，不是最优方案，您对这个如何看？

　　A：1、本人未使用过K8S布署产品；2、Redis监控体系，整体服务端，应用端，在Docker中也仅服务端可以，将metrcibeats这种集成在一起，但也有一些服务端监指标估算，需要自己编撰Agent来完成，也是可以到Docker中去。应用端的就没有办法了，这个属于后端的行为统计。

　　Q8：请问您的ES有多少节点？要用ssd盘吗？

　　A：1、标准集群，起步3个实例节点；2、固态硬盘应用看场景，业务系统用用可以，日志系统通常不需要，即使须要也可以做冷热隔离，少量的数据使用ssd，历史的数据全部hdd足矣。

　　Q9：如果公司缺少足够的人力物力，是用ES、Prometheus还是Zabbix做监控比较适宜呢？能分别说一下它们各自最适用的情况吗？

　　A：1、ES，Elastic-Stack，首选考虑，ES擅长的领域好多，应用系统查询加速、大数据领域、监控领域；2、其它两个产品主要是做指标型的监控，但实际项目中，仅仅指标监控是不够的，需要一个整体型的监控体系，便于联合剖析。ES虽然好多方面比时序数据库做得更好，腾讯有资深专家做过详尽的ES与TSDB对比的测试，性能与功能都完全超过专门的时序数据库。返回搜狐，查看更多