监控器内部原理¶
受网络、系统负载等因素影响，监控器的检测执行存在一些特殊的内部处理机制。
检测触发时间¶
用户配置的检测频率，在系统内部会转换为 Crontab 表达式。监控器将严格按此表达式定时启动，而非在创建或保存后，简单地每间隔 N 分钟执行一次。“
例如，用户为“监控器 A” 配置的执行频率为 “5 分钟”，其对应的 Crontab 表达式为 */5 * * * *。具体的触发时间关系如下：
| 动作 | 时间 |
|---|---|
| 用户创建/保存监控器 | 00:00:30 |
| 监控器触发检测 | 00:05:00 |
| 监控器触发检测 | 00:10:00 |
| ... | ... |
检测范围校准¶
由于平台需要处理所有用户配置的数千个监控器，同一时刻触发的检测任务无法同时执行，大部分任务会进入队列等待。
因此，多数检测任务会遇到计划在 T 时刻触发，但实际在 T + Δt 时刻才真正执行的情况。
如果直接使用实际执行时间作为查询的结束时间，会导致检测时间范围出现重叠或间隙。例如：
假设检测时间范围为 5 分钟：
| 动作 | 时间 | 实际查询的数据范围 |
|---|---|---|
| 1. 实际执行 | 00:05:10 |
00:00:10 ~ 00:05:10 |
| 2. 实际执行 | 00:10:05 |
00:05:05 ~ 00:10:05 |
| 3. 实际执行 | 00:15:30 |
00:10:30 ~ 00:15:30 |
在此情况下：
- “动作 1” 和“动作 2” 的检测范围在
00:05:05~00:05:10发生重叠； - “动作 2” 和“动作 3” 的检测范围在
00:10:05~00:10:30出现间隙，导致此时间段的数据未被覆盖。
现行解决方案¶
为避免因任务排队导致的检测范围波动，监控器的数据查询范围会以其计划触发时间为基准进行校准，而非实际执行时间。
假设检测时间范围为 5 分钟：
| 动作 | 时间 | 最终查询的数据范围 |
|---|---|---|
| 监控器触发检测（入队） | 00:05:00 |
|
| 监控器实际执行（出队） | 00:05:10 |
00:00:00 ~ 00:05:00 |
| 监控器触发检测（入队） | 00:10:00 |
|
| 监控器实际执行（出队） | 00:10:30 |
00:05:00 ~ 00:10:00 |
由此可见，无论检测任务排队多久，其数据查询范围始终基于计划触发时间，从而保证了时间窗口的连续性和稳定性。
注意
上述示例仅为说明“检测范围校准”原理，实际范围还会受“检测范围漂移”机制影响。
检测范围漂移¶
受网络延迟、数据处理等因素影响，数据上报后通常需要数秒至数十秒才能完成落盘（即可通过 DQL 查询到）。在此期间，监控器检测将无法查询到这些"在途"数据。
这容易导致按固定时间范围检测时，出现数据缺失。例如：
假设检测时间范围为 5 分钟：
| 动作 | 时间 | 检测范围 |
|---|---|---|
| 上报数据 A（尚未落盘） | 00:09:59 |
|
| 监控器触发检测 | 00:10:00 |
00:05:00 ~ 00:10:00 |
| 数据 A 落盘 | 00:10:05（数据时间戳为00:09:59） |
|
| 监控器触发检测 | 00:15:00 |
00:10:00 ~ 00:15:00 |
数据 A 虽然在第二次检测执行前已上报，但因首次检测时未落盘而被遗漏。待其落盘后，又因其时间戳较早，已不在后续检测的时间范围内，从而持续无法被检测到。
现行解决方案¶
为解决此问题，所有监控器在执行检测时，会自动将数据查询范围向历史方向漂移 1 分钟，以规避数据落盘期间的空窗期。
应用此方案后，上例变为：
假设检测时间范围为 5 分钟：
| 动作 | 时间 | 检测范围 |
|---|---|---|
| 上报数据 A（尚未落盘） | 00:09:59 |
|
| 监控器触发检测 | 00:10:00 |
00:04:00 ~ 00:09:00（漂移 1 分钟） |
| 数据 A 落盘 | 00:10:05（数据时间戳为00:09:59） |
|
| 监控器触发检测 | 00:15:00 |
00:09:00 ~ 00:14:00（漂移 1 分钟） |
数据 A 虽然在 00:10:00 的检测中被遗漏，但其时间戳 00:09:59 落在了 00:15:00 这次检测的范围内（00:09:00 ~ 00:14:00），因此能够在第二次检测中被成功捕获。
注意
若数据落盘延迟超过 1 分钟，此方案将失效，检测可能无法达到预期效果。
数据断档判断逻辑¶
观测云作为时序数据平台，不具备传统资产管理软件中的“资产总表”概念。系统只能基于已查询到的数据判断“存在”什么，而无法知晓“理应存在但当前不存在”的对象。
举例来说：
一个盒子里已知有铅笔和橡皮。我们可以明确说出“盒子里存在铅笔和橡皮”，但无法断言“盒子里不存在钢笔”，因为我们并不知道盒子“本该”有什么。
因此，监控器中的“数据断档检测”实际采用“边缘触发”机制进行判断，即通过对比连续两次的查询结果来发现变化。
其核心逻辑是：“若上一轮检测发现对象 X 存在，而本轮检测中对象 X 消失，则判定 X 发生数据断档”。
假设检测时间范围为 5 分钟：
00:00:00 ~ 00:05:00 结果 |
00:05:00 ~ 00:10:00 结果 |
判定结果 |
|---|---|---|
| 检测到数据 | 未检测到数据 | 数据断档 |
| 检测到数据 | 检测到数据 | 持续正常 |
| 未检测到数据 | 检测到数据 | 数据重新上报 |
| 未检测到数据 | 未检测到数据 | 持续无数据（无意义状态） |
注意
上述示例仅为说明核心逻辑。实际判断还会受“检测范围漂移”、“检测时间范围”以及“连续 N 分钟无数据才告警”等配置的影响。
数据断档 / 数据恢复事件¶
当监控器判定发生“数据断档”或“数据重新上报”时，会根据用户配置，决定是否生成“数据断档事件”或“数据断档恢复事件”。
为避免产生重复或无意义的告警，系统在生成事件前，会参考已存在的事件状态进行决策：
| 已存在的事件状态 | 本次检测判定结果 | 系统行动 |
|---|---|---|
| 无事件 / 数据断档恢复事件 | 数据断档 | 产生数据断档事件 |
| 无事件 / 数据断档事件 | 数据重新上报 | 产生数据断档恢复事件 |
因此，“数据断档事件”与“数据断档恢复事件”总是交替出现，不会出现连续的数据断档事件或连续的恢复事件。
常见问题¶
事件标明的时间与事件产生时间不符
在事件详情或告警通知中看到的时间（例如 00:15:00），是监控器的计划触发时间（即基于 Crontab 表达式的规整时间），而非事件在系统中实际生成的时间。
例外情况：如果您在监控器列表中手动点击“执行”，则产生的事件时间将为实际点击执行的时间。
事件标明的时间与实际故障发生的时间不符
事件标明的时间是监控器的计划触发时间，且由于存在“检测范围漂移”机制，实际检测的数据范围是 计划触发时间 - 检测范围 - 漂移时间 到 计划触发时间 - 漂移时间。
因此，实际发生故障的数据点时间，很可能不在 计划触发时间 - 检测范围 到 计划触发时间 这个直观区间内。这属于正常现象。
在平台中直接查询时发现疑似故障数据，但监控器未产生告警
此问题通常由以下原因导致：
- 数据落盘延迟过高：检测执行时，故障数据因延迟尚未可被查询；
- DQL 查询执行失败：检测过程因查询失败而中断。
此类情况通常源于数据链路或查询引擎的问题，不在监控器自身的控制范围内。