设置windowSize与evaluationFrequency相等时是否存在漏检故障风险？

当你把Azure警报的windowSize和evaluationFrequency设为相等（比如24小时检查过去24小时数据）时，确实存在因时钟偏差漏检故障的可能，核心问题出在系统时间不一致导致的时间窗口错位。

具体会漏检的场景 #

• 源数据与警报服务时间不同步：比如产生故障日志的服务器时钟比Azure Monitor快了10分钟。警报在当天零点触发，检查的是前一天零点到当天零点的窗口，但服务器上当天零点前10分钟发生的故障，时间戳会被标成当天零点10分，这部分数据就不在当前检查窗口里。而下一次警报要到第二天零点才会触发，检查当天零点到第二天零点的窗口——如果偏差一直存在，这个故障的时间戳可能刚好卡在两次窗口的缝隙里，直接被漏掉。
• 窗口衔接出现空隙：正常情况下，两个连续的检查窗口应该是无缝衔接的（第一次[0h,24h]，第二次[24h,48h]），但时钟偏差会让实际窗口要么重叠要么出现空隙。一旦出现空隙，那段时间的故障数据就不会被任何一次警报扫描到。

怎么降低这个风险 #

• 统一所有资源的时钟：确保所有产生监控数据的VM、应用服务、容器都同步到NTP服务器（Azure默认会做，但最好确认下资源的时钟配置没被手动修改），把偏差控制在几秒内。
• 设置窗口重叠：把windowSize设得比evaluationFrequency稍大一点，比如评估频率是24小时，窗口设成25小时。这样两次检查的窗口会有1小时的重叠，就算有小偏差，也能覆盖到边缘的故障数据。
• 日志查询加时间戳过滤：在警报的查询语句里，过滤掉时间戳明显异常的数据，比如排除比当前时间晚1小时或者比当前时间早25小时的日志，避免极端时间偏差带来的漏检或误报。

内容的提问来源于stack exchange，提问作者DataBach