有关「监控器」常见问题

2023-08-28

监控器由于其配置复杂，受外部影响多，很多人都会遇到实际行为与预期不符的情况。

本文以总结了经常遇到的问题以及正确的提问方式。

注意

监控器只是在规定时间，按照配置去执行 DQL 语句，并根据 DQL 返回值进行判断。（如果查不到数据，就进一步根据数据断档配置进行处理）

监控器不负责数据上报：数据上报频率，入库延迟请咨询数据采集端，监控器无法回答相关问题
监控器不负责数据库：用户配置了什么 DQL 监控器就执行什么 DQL，当时没查到数据就是没查到。你可以参考下文有关查不到数据的说明，但请勿来询问为什么没查到，因为你并没有在当时那个时间点去执行 DQL，不要拿监控器都执行完了才能查到的数据说事。

二次提示：不要在事后问我为什么查不到数据，事后能查到数据不代表监控器当时也能查到

快速判断表

预期与实际情况	可能原因
预期产生事件 / 告警，但实际未产生	1. 监控器修改过配置，且当前配置与历史行为不匹配 2. 数据上报入库延迟过大，导致检测时并没有查询到任何数据 3. 聚合函数选择了 Count 同时判断条件涉及 0 4. 监控器被禁用，不在运行静默 / 沉默规则影响 5. 数据库查询失败 / 写入操作失败
预期不产生事件 / 告警，但实际产生	1. 监控器修改过配置，且当前配置与历史行为不匹配 2. 数据上报入库延迟过大，导致检测时并没有查询到任何数据，从而产生数据断档告警

当遇到问题时，应当尽可能保留现场。如需做测试，应当另创建一个监控器。修改认为有问题的监控器，后续将很难排查当时的问题

1. 数据上报延迟过大，监控器无法查询到数据

物理限制

已知光在真空中的速度为 30 万公里每秒。电信号在铜线中的速度大约为 0.7 倍光速。

因此，即使用户上报的数据，完全忽略各种软硬件耗时，且以光速到达服务器并立即入库可查。也只有 300 公里以内的客户能做到延迟小于 1 毫秒。

由于数据上报入库延迟是客观存在且无法避免的，监控器为了保证每次运行检测时可以尽可能符合预期，实际用于检测的数据范围会偏移 1 分钟，即：

以「频率为 1 分钟，检测范围为 5 分钟」的监控器为例，在 00:30:00 时运行时，实际的检测数据范围为 00:28:00 ~ 00:29:00。

这样，可以保证数据上报入库延迟 1 分钟范围内的数据，依然可以被检测正常覆盖。

也因此，如果上报数据延迟超过 1 分钟，那监控器将不可能完成有效的检测。

以下是数据上报入库延迟导致无法查询到数据的示意表：

检测范围偏移 1 分钟检测范围无偏移

当前监控器方案，容许 1 分钟延迟

时间	数据上报	监控器检测
`00:28:59`	已上报，未入库
`00:30:00`	（延迟 62 秒）	查询`00:28:00 ~ 00:29:00`范围数据
`00:30:01`	已入库，已可查

这里只是示意无偏移的情况，不是当前监控器方案，主要展示没有容许范围的情况

时间	数据上报	监控器检测
`00:29:59`	已上报，未入库
`00:30:00`	（延迟 2 秒）	查询`00:29:00 ~ 00:30:00`范围数据
`00:30:01`	已入库，已可查

如何判断数据上报入库延迟是否过大？

目前 GuanceDB 对上报的数据都会自动添加create_time，可以使用 DQL 查询工具，查询time和create_time之间差值：

此方法仅作为参考，并不完备。且在以下场景中无效

数据上报端指定了数据时间time，但实际上报又远远晚于指定的时间（如：在 01:00 时上报了一条时间戳为 00:30 的数据）
落盘卡顿，即虽然在写入时添加当时时刻的create_time，但实际数据并不能立刻从数据库中查询得到。

Text Only
L::`DFF_task_record_func`:(create_time) limit 10

因此，根据本节内容，唯一可以做出的判断如下：

当上报端没有指定time，且在 DQL 查询工具中发现time、create_time差距过大时，可知数据上报必然存在较大延迟

P 可以推出 Q，不代表 Q 能推出 P

当「上报端没有指定time，且在 DQL 查询工具中能够发现time、create_time差距过大」，则「数据上报存在较大延迟」成立。

并不代表「数据上报存在较大延迟」，就「上报端没有指定time，且在 DQL 查询工具中能够发现time、create_time差距过大」。

P 可以推出 Q，不代表非 P 能推出非 Q

当「上报端没有指定time，且在 DQL 查询工具中能够发现time、create_time差距过大」，则「数据上报存在较大延迟」成立。

并不代表「上报端指定了time」时，「数据上报不存在较大延迟」。

也不代表「在 DQL 查询工具中没有发现time、create_time差距过大」时，「数据上报不存在较大延迟」。

数据上报入库延迟过大怎么办？

目前没有办法，上报入库延迟过大是导致检测失效的直接原因。

唯一能改善的方法是，将监控器的检测时间范围大于检测频率（如：每分钟检测，每次检测 5 分钟数据），使得同一个时间段的数据被多次检测，提高查询成功率。

但同时必然会带来同一时间段的数据被多次检测的副作用，告警可能会变多。

2. 监控器修改过配置，且与历史行为不匹配

请检查当前监控器配置，并判断是否与预期相符。

如不清楚是否有人修改，可以进入「管理 / 设置 / 安全 / 操作审计」来查看操作记录

3. 聚合函数选择了 Count 同时判断条件涉及 0

花名册原理

当没有花名册时，你只能知道谁在，但无法知道谁不在

由于观测云中的数据都是非结构化数据，且检测区分不同对象依赖BY语句，因此本来应该有哪些对象是不可知的。

与此同时，任何数据库（MySQL 也好，InfluxDB 也好），在使用聚合函数COUNT配合BY时，也是不可能返回COUNT == 0的条目的。

所以，在监控器配置中，单纯使用「聚合函数COUNT配合BY，再配置Result >= 0」是没有意义的。

如何实现「不存在」的检测？

此类检测实际检测的是「存在 XXX 告警」，同时配合「数据断档时产生恢复事件」对 COUNT 不到的对象产生恢复事件。

数据断档检测是如何实现的？

根据上述「花名册原理」，监控器并不知道「一共有多少对象」，但是可以知道「本轮 / 上轮检测范围有多少对象」。

通过「本轮检测范围内对象」和「上轮检测范围内对象」来判断，是否存在「数据断档」的对象，并将其判断为「数据断档」。

以下是数据断档对象判断的示意表：

检测轮数	检测范围内对象	结果
第一轮	张三、李四	-
第二轮	李四	和上一轮相比，缺少了「李四」因此，「李四」为数据断档对象

4. 静默 / 沉默规则影响

静默 / 沉默规则只会影响告警是否发送，不影响事件的产生。

可以直接查看事件详情中的信息，了解为什么静默 / 沉默。

X. 如何进行有效的提问

如果上述常见问题都无法解决你的问题，那么你可以尝试按照如下方式提问：

预期产生事件 / 告警，但实际未产生预期不产生事件 / 告警，但实际产生

请提交以下5 项内容至研发侧，研发侧会根据提交的信息查询系统日志，以判断是否存在问题。

请完整提交以下 5 项内容，缺少内容会导致问题无法定位

#	提交内容	来源
1	哪个观测云节点？	可以直接复制地址栏 URL 地址如：`cn3-console.guance.com`就是`cn3`
2	哪个工作空间？	可以在「管理 / 设置」中查看「工作空间 ID」工作空间 ID 格式为`wksp_xxxxx`
3	哪个监控器？	可以在监控器配置页面，直接复制地址栏 URL 监控器 ID 格式一定是`rul_xxxxx`
4	什么时候？	请提供准确的时间如：`2023-01-01 00:10:00` 不要写类似「昨天中午」、「之前」、「刚刚」这种模糊的，随着时间推移意义会发生变化的描述
5	问题描述	简要说明「为什么你会觉得应该产生事件 / 告警」

请提交以下2 项内容至研发侧，研发侧会根据提交的信息查询系统日志，以判断是否存在问题。

请完整提交以下 2 项内容，缺少内容会导致问题无法定位

#	提交内容	来源
1	事件 JSON 文件	可在「事件详情 / 导出 / 导出 JSON 文件」下载事件的 JSON 文件
2	问题描述	简要说明「为什么你会觉得不应该产生事件 / 告警」