这是一个创建于 62 天前的主题，其中的信息可能已经有所发展或是发生改变。
区间为 5s ，00:00 的 hit 与 miss 值与 00:05 的值都相等，也就是说 5s 里 redis 都没有 qps 。那此时的命中率应该是多少呢？
-----
在阿里云上，从 Redis 开源版 4.0 升级至 5.0 后，命中率监控持续报警说命中率只有 40%左右。通过 info 查看，自己按照 `命中率=Key 命中数÷（ Key 命中数+Key 未命中数）`计算，命中率应该在 90%以上，遂提交工单询问监控命中率计算问题。经过 3 个半小时的内部讨论给了如下回复(忽略标题内容)。
阿里云命中率指标的获取最小周期是 5s ，也就是 5s 内都没有 QPS 的时候，这 5s 的命中率就为 0 （以前为 100%）。除非每秒都有 QPS ，那在阿里云云监控中，那刻的命中率才会显示为 100%。下图就是为 0 的情况。
越看这个逻辑越别扭。像上图这种正常情况下，命中率指标能覆盖 0%-100%，这还咋设置监控呢。
我们业务无法保障每秒都有 qps ，按照现在的算法，1 分钟的区间，晚上的命中率能到 10%，白天可能到 80%，监控命中率完全无法设置阈值，如果设置过低，白天的 key miss 可能就无法触发报警，设置略高，晚上报警不断。。。
-----
在阿里云上，从 Redis 开源版 4.0 升级至 5.0 后，命中率监控持续报警说命中率只有 40%左右。通过 info 查看，自己按照 `命中率=Key 命中数÷（ Key 命中数+Key 未命中数）`计算，命中率应该在 90%以上，遂提交工单询问监控命中率计算问题。经过 3 个半小时的内部讨论给了如下回复(忽略标题内容)。
阿里云命中率指标的获取最小周期是 5s ，也就是 5s 内都没有 QPS 的时候，这 5s 的命中率就为 0 （以前为 100%）。除非每秒都有 QPS ，那在阿里云云监控中，那刻的命中率才会显示为 100%。下图就是为 0 的情况。
越看这个逻辑越别扭。像上图这种正常情况下，命中率指标能覆盖 0%-100%，这还咋设置监控呢。
我们业务无法保障每秒都有 qps ，按照现在的算法，1 分钟的区间，晚上的命中率能到 10%，白天可能到 80%，监控命中率完全无法设置阈值，如果设置过低，白天的 key miss 可能就无法触发报警，设置略高，晚上报警不断。。。
 | 1 huangsijun17 62 天前 1. null 值处理问题。 2. 能不能调低采集维度？ 3. 告警按照时间段设置？ |
 | 2 Vraw5 OP @huangsijun17 #1 获取数据的操作是阿里云那边做的，我们只能配置监控报警规则的阈值，所以 1 和 2 都做不了。3 告警时间可以配置。 主要问题还是无法覆盖真实的 key miss 的情况，因为无 qps 会弄脏统计结果 |
 | 3 opengps 62 天前 计算公式里本身就藏着这么个问题，无访问时候的 qps 写成 0%或者 100%都有副作用。这时候确实得考虑写个定时循环每秒读取 1 次 |
| 4 Vraw5 OP @opengps #3 我是这么想的。如果设置成 100%时，监控上出现 100%，要么没有 QPS 要么都命中了，业务上是没出现问题的，不需要告警。即使会拉高命中率，也可以通过拉高报警规则的阈值或者降低周期去配置。如果设置成 0 ，完全无法区分到底是因为没有 QPS 造成还是因为 misses 过多造成的命中率低。 所以我难以理解为啥阿里云会变更这个规则 |
 | 7 spritecn 62 天前 写个 job,每秒写个随机值进去读一下 |
 | 9 BenHunDun 61 天前 不知道有没有统计请求量, 感觉这个监控预警是不是应该要有一个最低请求量限制. 即其实在某个请求量下, 其实未命中 key , 访问数据库对业务方是能够接受. 不会对系统造成危害. 通过降低提示等级到 warn, info 提示用户. |
Select Language