我为什么用ES做Redis监控 不需Prometheus或Zabbix
发布时间：2022-07-18 09:50:16 所属栏目：安全 来源：互联网
导读：Elastic-Stack产品深度用户，ES认证工程师，对Elastic-Stack开发、架构、运维有深入体验; 实践过多种ES项目，最暴力的大数据分析应用，最复杂的业务系统应用。 系统刚开始关于Redis的一切都很正常，随着应用系统接入越来越多，应用系统子模块接入也越来越多
|
Elastic-Stack产品深度用户，ES认证工程师，对Elastic-Stack开发、架构、运维有深入体验; 实践过多种ES项目，最暴力的大数据分析应用，最复杂的业务系统应用。 系统刚开始关于Redis的一切都很正常，随着应用系统接入越来越多，应用系统子模块接入也越来越多，开始出现一些问题，应用系统有感知，集群服务端也有感知，如下描述： 集群节点崩溃; 集群节点假死; 某些后端应用访问集群响应特别慢。 其实问题的根源都是架构运维层面的欠缺，对于Redis集群服务端的运行监控其实很好做，本身也提供了很多直接的命令方式，但只能看到服务端的一些常用指标信息，无法深入分析，治标不治本，对于Redis的内部运行一无所知，特别是对于业务应用如何使用Redis集群一无所知： Redis集群使用的热度问题? 哪些应用占用的Redis内存资源多? 哪些应用占用Redis访问数最高? 哪些应用使用Redis类型不合理? 应用系统模块使用Redis资源分布怎么样? 应用使用Redis集群的热点问题? 监控体系 监控的目的不仅仅是监控Redis本身，而是为了更好的使用Redis。传统的监控一般比较单一化，没有系统化，但对于Redis来说，个人认为至少包括：一是服务端，二是应用端，三是服务端与应用端联合分析。 服务端： 服务端首先是操作系统层面，常用的CPU、内存、网络IO，磁盘IO，服务端运行的进程信息等; Redis运行进程信息，包括服务端运行信息、客户端连接数、内存消耗、持久化信息 、键值数量、主从同步、命令统计、集群信息等; Redis运行日志，日志中会记录一些重要的操作进程，如运行持久化时，可以有效帮助分析崩溃假死的程序。 （编辑：应用网_丽江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330468号