推荐先阅读官方文档监控功能（5秒粒度）

结论先行

• Proxy节点告警触发条件推荐设置（仅供参考）

平均执行时延 >= 30ms，持续1分钟，按1小时重复告警

最大执行时延 >= 100ms，持续1分钟，按1小时重复告警

出流量使用率 >= 80%，持续1分钟，按1小时重复告警

出流量限流触发 >= 1Count，持续5秒，按1小时重复告警

入流量使用率 >= 80%，持续5秒，按1小时重复告警

入流量限流触发 >= 1Count，持续5秒，按1小时重复告警

连接使用率 >= 80%，持续1分钟，按1小时重复告警

Mget请求数 >= 1000Count/s，持续1分钟，按1小时重复告警

CPU使用率 >= 80%，持续1分钟，按1小时重复告警

• Redis节点告警触发条件推荐设置（仅供参考）

总请求 >= 60000Count/s，持续1分钟，按1小时重复告警

CPU使用率 >= 80%，持续1分钟，按1小时重复告警

复制延迟 >= 1024000Bytes，持续1分钟，按1小时重复告警

慢查询 >= 50Count，持续1分钟，按1小时重复告警

内存使用率 >= 80%，持续1分钟，按1小时重复告警

key过期数 >= 30000Count，持续1分钟，按1小时重复告警

key驱逐数 >= 10000Count，持续1分钟，按1小时重复告警

腾讯云新版本监控（5秒粒度）简要介绍

腾讯云新版本监控（5秒粒度）已经灰度3个多月了，原有的分钟级粒度的监控版本仍然会继续保留一段时间，有条件的企业和开发者推荐升级至5秒监控，后续官方应该会提供合适的升级方案。

新监控的区别

• 监控维度升级
  从分钟级粒度升级至5s粒度
• 区分了proxy监控和redis节点监控
  无论是云数据库 Redis 标准架构还是集群架构都包含 Proxy了，业务访问腾讯云redis的访问链路都是先访问vip，vip通过负载均衡连接到不同的proxy，proxy连接到后端的redis节点。因此新监控区分了proxy监控和redis监控
• 区分了redis主节点监控和副本节点监控
  redis可以通过增加副本提升容灾以及开通读写分离提高读性能，因此在开通读写分离的情况下，如果读请求出现瓶颈，不监控副本节点是不利于定位问题的
• 提供了实例监控聚合视图
  登录 Redis 控制台，单击实例名进入实例管理页面，选择【系统监控】>【监控指标】，可查看实例监控信息详情

该视图是新版本我个人认为最有价值的部分，可以非常直观的看出各个redis存储节点、各个proxy的运行情况，非常便于抓出异常信息和异常节点

监控指标说明

详细的监控指标，请点击本页最上方链接参考官方文档，这里只给出一些笔者认为比较关键的指标

proxy节点监控

• Mget 请求数
  Mget是非常消耗系统资源的，尤其是对于集群版性能损耗会更加严重，可以这样说，redis cluster 模式天然不适合大规模mget的场景
  注意：Mget虽然对系统资源的压力比较大，但是并没有一个放之四海而皆准的阈值可以反映当前redis的mget健康阈值，一般认为1次Mget的key的数量最好不要超过20个，如果多了要进行拆分，Mget的并发峰值最好不要超过1000个，当然上面两个指标并不绝对，仅供参考，更要结合CPU、流量、qps、访问延时等指标进行综合分析
• 大 Value 请求
  一般我们认为string类型超过10KB大小，元素个数超过10240个的key被称为是大key，这里监控的大key标准是32KB，合理的建议是不应该有大key，应尽早对大key进行拆分，值得注意的是，大key请求没有一个确定阈值，对于几个G的大key来说，1qps就会导致实例卡死、流量打满甚至引发HA切换，10kB级别的大key可能达到上千qps都不会引发性能瓶颈，和Mget请求数一样，没有固定阈值，要结合CPU、流量、qps、访问延时等指标进行综合分析
• 连接使用率
  这里指的是业务侧连接到proxy的连接使用率，客户在控制台购买实例，挑选规格时候的流量、连接数均是在proxy层面进行的控制，建议连接数使用率告警阈值控制在60~80%
• 入流量限流触发
  新版本的亮眼特性，阈值最低设置为1，只要出现就证明了入流量成为瓶颈，一般而言入流量出现瓶颈几率比较小，更多是出流量成为瓶颈
• 出流量限流触发
  新版本的亮眼特性，阈值最低设置为1，只要出现就证明了出流量成为瓶颈同时伴随业务超时、大量慢查询等，qps过高、拉取大key、高并发mget等容易触发瓶颈，可通过控制台自助调整流量配额优先恢复
• 平均执行时延
  最能直观反映业务访问情况的指标，强烈建议配置，可根据需求灵活设置阈值，redis是高吞吐、高性能的存储模型，一般认为5ms以上就可以视为出现性能瓶颈，推荐设置5ms~50ms，可根据业务需要灵活设置。
• 最大执行时延
  搭配平均时延一起监控，推荐设置10ms~100ms，可根据业务需要灵活设置。

redis节点监控

• CPU 使用率
  redis节点的平均 CPU 使用率，推荐设置60%~80%
• 内存使用率
  推荐设置80%~90%，需要注意的是，如果内存清理策略设置为allkeys-lru，理论上100%也不会导致写入失败，但是在内存清理时会导致实例有一定的卡顿现象。
• 复制延迟
  通常，redis主从复制延迟在ms级别，常见的在1ms~5ms之间，对主从延迟特别敏感的场景不建议开通读写分离，更适用于读副本延迟不敏感的场景，阈值可灵活设置，注意，redis复制延迟是按照数据量的差距而非毫秒，因此该值更能准确评估延迟情况，个人推荐配置10KB~200kB，也要看业务的真实情况。
• 总请求
  通常，主从版qps 5万以上，集群版qps单分片5w以上开始出现性能瓶颈，6~7万以上有比较明显的耗时增加，推荐设置6w的qps，当然这个值也不是固定的，也和访问的key大小和命令本身复杂度有关系
• 慢查询
  这里主要记录的是执行时延大于 slowlog-log-slower-than 配置的命令次数，因此配置合理的慢查询阈值是非常有必要的，这里推荐配置慢查询阈值10~100ms，参数默认值为500ms，这个默认值明显太大了，相信后续官方会进行更新
• key 过期数
  由于redis对过期key的清理遵循惰性淘汰和定期淘汰，大批量集中的key过期也可能导致实例卡顿、业务时延增加，同样的，和过期key的大小有关系，这个值没有固定的参考阈值，超过1GB的大key可能1个过期就会有明显的感知，普通的key可能数万过期也感知不到，这个值建议作为辅助参考指标

推荐云监控配置

注意：下面的告警配置仅供参考，实际生产中还需要考虑业务场景、负载模型和一些其他要素。

推荐proxy节点告警配置

推荐redis节点告警配置