监控器内部原理¶
监控器检测的执行，由于受到网络、系统等限制，存在一些特殊处理。
1、检测触发时间¶
用户配置的检测频率，实际内部会转换为 Crontab 表达式，监控器实际会按照此 Crontab 表达式启动，而非创建/保存后每 N 分钟执行。
假设用户为「监控器 A」配置了执行频率为「5 分钟」，那么，对应的 Crontab 表达式为 */5 * * * *，即实际触发时间如下表：
| 动作 | 时间 |
|---|---|
| 用户创建/保存监控器 | 00:00:30 |
| 监控器触发检测 | 00:05:00 |
| 监控器触发检测 | 00:10:00 |
| 监控器触发检测 | 00:15:00 |
| 监控器触发检测 | 00:20:00 |
| ... | ... |
2、检测范围校准¶
由于平台承载了所有用户配置的数千个检测器，同一个时间点触发的检测处理并不可能同时执行，绝大多数任务都会进入队列等待。
因此，大部分检测处理会遇到本应在 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 之间的数据未被检测所覆盖。
现行解决方案¶
为了避免排队延迟导致检测范围的波动，监控器的检测范围（即 DQL 查询数据范围）都会根据其触发时间进行校准，如：
假设检测范围为 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 |
可以看到，无论一次检测在排队后等待了多久，其检测范围都是根据【触发时间】来确定，并不以实际执行时间而产生波动。
注意：上述表格仅为描述「检测范围校准」的示意，实际检测范围还会受到「检测范围漂移」影响。
3. 检测范围漂移¶
由于网络延迟，数据落盘延迟等影响，数据上报一般都会有若干秒，甚至几十秒的延迟。具体表现为刚上报的数据无法通过 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 在检测执行前已经上报，但由于尚未落盘，因此在监控器检测时无法查询到数据 A。
同时，即使等到数据 A 落盘，由于其数据时间戳为较早的时间，下一轮监控器也无法检测到数据 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 虽然存在落盘延迟，但在第二轮的检测中，依然能够被检测到，从而避免了落盘延迟导致的检测数据缺失。
注意：如遇到落盘延迟超过 1 分钟的情况，本方案会失效，检测无法产生预期的效果
4. 数据断档判断逻辑¶
由于观测云是基于时序数据的平台，并不像非资产管理类软件那样，存在资产列表总表。实际只能够以可查询到的数据认为「存在」，并不能了解「哪些对象不存在」。
假设我有一个盒子，里面有铅笔、橡皮。
那么，我可以很明确得说出，「盒子里存在铅笔、橡皮」，
但我无法说出「盒子里不存在什么」。
因为我并不知道「盒子里本来应该有什么」（即资产总表）
因此，监控器中的「数据断档检测」实际都只能按照「边缘触发」的方式来判断数据的断档和恢复。
即「上一轮查询我发现有 X，本轮查询查不到 X，那么 X 发生数据断档」。
如：
假设检测范围为 5 分钟
00:00:00 ~ 00:05:00 |
00:05:00 ~ 00:10:00 |
判定结果 |
|---|---|---|
| 有数据 | 数据断档 | |
| 有数据 | 有数据 | 持续正常 |
| 有数据 | 数据重新上报 | |
| 持续数据断档（无意义的判断） |
注意：上述表格仅为描述「数据断档判断逻辑」的示意，实际两次检测范围还会受到「检测范围漂移」、「检测范围」、「连续 N 分钟内出现数据断档」等配置的影响。
5. 数据断档 / 数据断档恢复事件¶
当监控器发现数据存在「数据断档」、「数据重新上报」后，根据用户在监控器中的不同配置，可能会产生「数据断档事件」或「数据断档恢复事件」。
但为了避免无意义的重复告警，在产生上述事件之前，会根据已存在的事件进行判断，是否需要生成对应事件：
| 上一次事件 | 本次检测判定结果 | 结果 |
|---|---|---|
| 无事件/数据断档恢复事件 | 数据断档 | 产生数据断档事件 |
| 无事件/数据断档事件 | 数据重新上报 | 产生数据断档恢复事件 |
因此，「数据断档事件」与「数据断档恢复事件」总是成对出现，不会出现连续的「数据断档事件」或者连续的「数据断档恢复事件」
X. 常见问题¶
事件标明的时间与事件产生时间不符¶
事件详情、告警通知中，都会标明一个时间，如：00:15:00。
这里的标明时间都是监控器的「检测触发时间」，即 Crontab 表达式所表达的时间，一定是规整的检测频率倍数。
例外：如果你在监控器列表中手工点击了执行，那么对应产生的事件时间为实际执行时间
事件标明的时间与实际故障数据点时间不符¶
事件标明的时间都是监控器的「检测触发时间」，且由于存在「检测范围漂移」，确实可能存在实际故障数据点时间在「检测触发时间 - 检测范围 ~ 检测触发时间」区间外的情况。
因为实际的检测范围为「检测触发时间 - 检测范围 - 漂移时间 ~ 检测触发时间 - 漂移时间」
此情况为正常现象。
在观测云中直接查看数据发现应当存在故障，但监控器未检测出故障¶
此问题产生的原因如下：
- 由于上报数据入库落盘延迟过大，导致检测实际执行时，故障点数据无法查询。
- 检测执行时，DQL 查询失败导致检测中断。
此情况不属于监控器可控范畴。