有关「监控器」常见问题
2023-08-28
监控器由于其配置复杂，受外部影响多，很多人都会遇到实际行为与预期不符的情况。
本文以总结了经常遇到的问题以及正确的提问方式。
不要再来询问，为什么监控器检测不到数据 / 检测数据与实际不符
监控器只是在规定时间，按照配置去执行 DQL 语句，并根据 DQL 返回值进行判断。（如果查不到数据，就进一步根据数据断档配置进行处理）
- 监控器不负责数据上报：数据上报频率，入库延迟请咨询数据采集端，监控器无法回答相关问题
- 监控器不负责数据库：用户配置了什么 DQL 监控器就执行什么 DQL，当时没查到数据就是没查到。你可以参考下文有关查不到数据的说明，但请勿来询问为什么没查到，因为你并没有在当时那个时间点去执行 DQL，不要拿监控器都执行完了才能查到的数据说事。
二次提示：不要在事后问我为什么查不到数据，事后能查到数据不代表监控器当时也能查到
快速判断表
| 预期与实际情况 | 可能原因 |
|---|---|
| 预期产生事件 / 告警，但实际未产生 | 1. 监控器修改过配置，且当前配置与历史行为不匹配 2. 数据上报入库延迟过大，导致检测时并没有查询到任何数据 3. 聚合函数选择了 Count 同时判断条件涉及 0 4. 监控器被禁用，不在运行 静默 / 沉默规则影响 5. 数据库查询失败 / 写入操作失败 |
| 预期不产生事件 / 告警，但实际产生 | 1. 监控器修改过配置，且当前配置与历史行为不匹配 2. 数据上报入库延迟过大，导致检测时并没有查询到任何数据，从而产生数据断档告警 |
| 监控器执行慢 / 队列 8 堵塞 | 1. worker-8 数量太少，监控器太多，来不及跑2. 监控器执行 DQL 返回慢，导致单位时间能运行的监控器少 3. 用户配置监控器检测对象过多（即 DQL 返回的时间线数量巨大） 4. 关联配置数量过多，比如使用脚本刷出来的大量告警策略、通知对象、静默规则 |
当遇到问题时，应当尽可能保留现场。如需做测试，应当另创建一个监控器。修改认为有问题的监控器，后续将很难排查当时的问题
1. 数据上报延迟过大，监控器无法查询到数据
物理限制
已知光在真空中的速度为 30 万公里每秒。电信号在铜线中的速度大约为 0.7 倍光速。
因此，即使用户上报的数据，完全忽略各种软硬件耗时，且以光速到达服务器并立即入库可查。也只有 300 公里以内的客户能做到延迟小于 1 毫秒。
由于数据上报入库延迟是客观存在且无法避免的，监控器为了保证每次运行检测时可以尽可能符合预期，实际检测执行时间延后 30 秒（旧版本中为 1 分钟），即：
以「频率为 1 分钟」的监控器为例，原计划在 00:30:00 时运行的监控器，实际会在 (00:30:00 + 延迟) 运行。
这样，可以保证数据上报入库存在少许延迟的数据，依然可以被检测正常覆盖。
也因此，如果上报数据延迟过大，那监控器将不可能完成有效的检测。
以下是数据上报入库延迟导致无法查询到数据的示意表：
当前监控器方案，容许一定延迟
| 时间 | 数据上报 | 监控器检测 |
|---|---|---|
00:29:59 |
已上报，未入库 | 等待 |
00:30:00 |
未入库，不可查 | 计划执行，但尚未实际执行 |
00:30:01 |
已入库，已可查 | 等待 |
00:31:00 |
已入库，已可查 | 实际执行，可正确查询到数据 |
| 时间 | 数据上报 | 监控器检测 |
|---|---|---|
00:29:59 |
已上报，未入库 | 等待 |
00:30:00 |
未入库，不可查 | 实际执行，但无法查询到数据 |
00:30:01 |
已入库，已可查 |
2. 如何判断数据上报入库延迟是否过大？
目前 GuanceDB 对上报的数据都会自动添加 create_time，可以使用 DQL 查询工具，查询 time 和 create_time 之间差值：
此方法仅作为参考，并不完备。且在以下场景中无效
- 数据上报端指定了数据时间
time，但实际上报又远远晚于指定的时间（如：在 01:00 时上报了一条时间戳为 00:30 的数据） - 落盘卡顿，即虽然在写入时添加当时时刻的
create_time，但实际数据并不能立刻从数据库中查询得到。
| Text Only | |
|---|---|
1 | |
因此，根据本节内容，唯一可以做出的判断如下：
当上报端没有指定
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 差距过大」时，「数据上报不存在较大延迟」。
3. 数据上报入库延迟过大怎么办？
目前没有办法，上报入库延迟过大是导致检测失效的直接原因。
唯一能改善的方法是，将监控器的检测时间范围大于检测频率（如：每分钟检测，每次检测 5 分钟数据），使得同一个时间段的数据被多次检测，提高查询成功率。
但同时必然会带来同一时间段的数据被多次检测的副作用，告警可能会变多。
4. 监控器配置与实际行为不一致，怎么办？
请检查当前监控器配置，并与监控器日志中的参数进行对比，检查是否一致。
如不一致，可能是因为 Studio 在保存时未正确在 Func 中设置
如一致，说明监控器本身没有问题，可以进入「管理 / 设置 / 安全 / 操作审计」来查看操作记录，确认是否有人之前修改过配置
5. 聚合函数选择了 Count 同时判断条件涉及 0，查不到为 0 的对象
花名册原理
当没有花名册时，你只能知道谁在，但不知道谁不在
由于观测云中的数据都是非结构化数据，且检测区分不同对象依赖 BY 语句，因此本来应该有哪些对象是不可知的。
与此同时，任何数据库（MySQL 也好，InfluxDB 也好），在使用聚合函数 COUNT 配合 BY 时，也是不可能返回 COUNT == 0 的条目的。
所以，在监控器配置中，单纯使用「聚合函数 COUNT 配合 BY，再配置 Result >= 0」是没有意义的。
6. 数据断档检测是如何实现的？
监控器在每轮运行时，都会记录可以查询到的对象并缓存
当某个对象在较长一段时间内都没有被查询到时，会自动从缓存中排除。
通过「缓存的对象」和「本轮检测范围内对象」来判断，对象是否存在「数据断档」。
以下是数据断档对象判断的示意表：
| 检测轮数 | 检测范围内对象 | 缓存的对象 | 结果 |
|---|---|---|---|
| 1 | 张三 | 张三 | |
| 2 | 张三、李四 | 张三、李四 | |
| 3 | 李四 | 张三、李四 | 张三对象存在数据断档 |
7. 配置了静默规则后，事件依然存在
静默规则只会影响告警是否发送，不影响事件的产生。
8. 监控器执行慢 / 队列 8 堵塞
worker-8数量太少，监控器太多，来不及跑- 监控器执行 DQL 返回慢，导致单位时间能运行的监控器少
- 用户配置监控器检测对象过多（即 DQL 返回的时间线数量巨大）
- 关联配置数量过多，比如使用脚本刷出来的大量告警策略、通知对象、静默规则
X. 如何进行有效的提问
如果上述常见问题都无法解决你的问题，那么你可以尝试按照如下方式提问：
请提交以下5 项内容至研发侧，研发侧会根据提交的信息查询系统日志，以判断是否存在问题。
请完整提交以下 5 项内容，缺少内容会导致问题无法定位
| # | 提交内容 | 来源 |
|---|---|---|
| 1 | 哪个观测云节点？ | 可以直接复制地址栏 URL 地址 如： cn3-console.guance.com 就是 cn3 |
| 2 | 哪个工作空间？ | 可以在「管理 / 设置」中查看「工作空间 ID」 工作空间 ID 格式为 wksp_xxxxx |
| 3 | 哪个监控器？ | 可以在监控器配置页面，直接页面左上方的 ID 监控器 ID 格式一定是 rul_xxxxx |
| 4 | 什么时候？ | 请提供准确的时间如：2023-01-01 00:10:00不要写类似「昨天中午」、「之前」、「刚刚」这种模糊的，随着时间推移意义会发生变化的描述 |
| 5 | 问题描述 | 简要说明「为什么你会觉得应该产生事件 / 告警」 |
请提交以下2 项内容至研发侧，研发侧会根据提交的信息查询系统日志，以判断是否存在问题。
请完整提交以下 2 项内容，缺少内容会导致问题无法定位
| # | 提交内容 | 来源 |
|---|---|---|
| 1 | 事件 JSON 文件 | 可在「事件详情 / 导出 / 导出 JSON 文件」下载事件的 JSON 文件 |
| 2 | 问题描述 | 简要说明「为什么你会觉得不应该产生事件 / 告警」 |
