我为什么用ES做Redis监控

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

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

• 开发层面
• 架构层面
• 运维层面

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

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

Redis监控体系有哪些方面?

构建Redis监控体系我们做了哪些工作?

Redis监控体系应该细化到什么程度?

为什么使用ELK构建监控体系?

 

些问题，应用系统有感知，集群服务端也有感知，如下描述：

• 集群节点崩溃;
• 集群节点假死;
• 某些后端应用访问集群响应特别慢。

其实问题的根源都是架构运维层面的欠缺，对于Redis集群服务端的运行监控其实很好做，本身也提供了很多直接的命令方式，但只能看到服务端的一些常用指标信息，无法深入分析，治标不治本，对于Redis的内部运行一无所知，特别是对于业务应用如何使用Redis集群一无所知：

• Redis集群使用的热度问题?
• 哪些应用占用的Redis内存资源多?
• 哪些应用占用Redis访问数最高?
• 哪些应用使用Redis类型不合理?
• 应用系统模块使用Redis资源分布怎么样?
• 应用使用Redis集群的热点问题?

监控体系

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

服务端：

• 服务端首先是操作系统层面，常用的CPU、内存、网络IO，磁盘IO，服务端运行的进程信息等;
• Redis运行进程信息，包括服务端运行信息、客户端连接数、内存消耗、持久化信息 、键值数量、主从同步、命令统计、集群信息等;
• Redis运行日志，日志中会记录一些重要的操作进程，如运行持久化时，可以有效帮助分析崩溃假死的程序。

  （编辑：淮安站长网）

  【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!