（关注“数据库架构师”公众号，提升数据库技能，助力职业发展）
Redis作为核心缓存服务，目前已经成为互联网公司的标配。目前我们维护的Redis集群规模：每日总请求超过10000亿次，Redis节点超过10000个，服务器500台，覆盖全部业务线，支持了包括数据缓存、消息队列、分布式锁等各种核心应用场景，应用的服务也越来越重要。作为DBA，运维了这么久Redis，发现我们不少开发人员在使用Redis时，对于一些非常核心的监控指标缺乏了解，特整理如下，希望给大家带来帮助。
1.访问QPS统计
指标解读：
QPS反应了每秒Redis处理的命令数。如果这个指标有较大波动或者或预期不一致需要警惕。运维中我们发现不少应用程序框架每次发送命令时会先发一个ping探活，导致QPS值翻倍，建议关闭。
2.执行命令统计
指标解读：
该指标展示了当前Redis节点最近一周时间访问最多的命令Top5统计。因为每套集群存储的数据结构类型不同，使用的访问命令也不同，所以这里大家会发现不同的集群命令不同。
3.命中率统计
指标解读：
该指标展示了当前Redis节点每秒请求命令的命中情况，对于用于缓存服务的场景参考意义很大。如果自己的应用高度依赖缓存，那么如果出现业务响应时间变长时，要优先关注这个指标的波动情况。
4.Key数量监控
指标解读：
该指标展示了当前Redis节点Key数量的变化情况，如果内存波动厉害，建议优先关注这个参数值的变化。注意：这里也统计了过期Key数量的变化，对于缓存的应用，建议都要合理设置过期时间。
5.内存使用统计
指标解读：
Redis应用非常重要的指标，一般内存使用上限不要超过30G，在使用率超过90%时，会有报警提示。内存使用主要有两个指标：实际使用内存和数据内存。
- 实际使用内存：操作系统分配给Redis实例的内存大小，表示该进程所占物理内存的大小。另外这个指标还包含了内存碎片的开销，内存碎片是由操作系统低效的分配/回收物理内存导致的
- 数据内存：就是实际数据占用的内存大小
- 碎片率：实际使用内存/数据内存 , 碎片率不宜过大，否则会影响请求的响应时间
6.连接数统计
指标解读：
Redis内处理请求的连接数，上限为10000.正常的应用请求连接数应该比较平稳，如果出现忽高忽低现象，需要警惕是否有命令阻塞或者网络异常情况。另外应用侧jedis连接池的默认连接数最大为8个，如果访问量较大一定要记得调大该值。
7.网络流量统计
指标解读：
Redis请求的网络流量进和出的统计。早期不少redis部署在千兆服务器上，如果业务请求的Key-Value过大或者使用了hgetall等批量获取的命令，很容易会将网卡打爆。如果发现自己业务响应时间时高时低甚至请求错误，也记得要关注该指标。
8.CPU负载
指标解读：
该指标包含两项，user 指的是指令在用户态（User Mode）所消耗的CPU时间
sys指的是指令在核心态（Kernel Mode）所消耗的CPU时间。如果两者之和超过75，说明CPU比较繁忙了，需要警惕是不是访问的QPS特别高或者有慢操作的命令。因为Redis单线程架构，如果达到100，就说明CPU满负荷运行，会影响请求的处理响应时间。
如果这篇文章对你有帮助，还请帮忙点赞、转发 以下，你的支持会激励我们输出更多高质量的文章！
如果你还想看更多优质文章，欢迎关注我的公众号「数据库架构师」，提升数据库技能，助力职业发展。