监控器原理说明

概述

监控器是一种基于周期性数据查询的主动告警机制。它按照用户配置的检测区间，定时从数据存储中拉取指标、日志或其他类型的时序数据，并根据预设的触发条件判断是否生成告警事件。

监控器的工作流程分为三个核心阶段：

• 数据查询阶段 ：按检测区间定时执行指标或 PQL 查询，获取聚合后的数值结果；
• 事件判断阶段 ：将查询结果与触发条件中的阈值进行比对，判断当前周期是否满足告警条件；
• 告警通知阶段 ：在事件等级确定后，根据告警内容模板和通知策略向指定渠道发送通知。

检测规则

检测规则是监控器的核心配置部分，定义了数据来源、查询方式、检测频率及告警触发逻辑。

生效范围

用于限定监控器所监控的资源对象范围。生效范围的本质是为查询语句附加过滤条件，使检测精确作用于目标资源，避免全量数据扫描带来的噪音和性能开销。

检测区间

检测区间决定了每次查询所覆盖的数据时间窗口。例如将检测区间设置为 5 分钟，则每次执行时查询过去 5 分钟内的数据。

内部原理 ：系统并不会恰好在整点触发检测，而是在服务启动时随机分配一个偏移量（jitter），以打散不同监控器的并发执行，避免集中式查询压垮存储层。

触发条件

触发条件决定了何时产生告警事件，包含以下核心要素：

连续触发次数

配置项：当结果数据连续 N 次 > 阈值时触发。

系统在每个检测周期内执行一次查询，并将结果与阈值比较。只有当连续 N 个周期的结果均满足条件时，才会真正生成告警事件。该设计可有效降低因数据抖动或短暂峰值引发的误报。

• N = 1 ：只要当前周期满足条件即立即告警，适用于对实时性要求高的场景；
• N > 1 ：需要连续多个周期均满足条件才告警，适用于持续性异常检测，可过滤瞬时抖动。

事件等级阈值

等级	说明
致命（Critical）	最高严重级别，通常对应服务完全不可用或数据指标极度异常，需立即响应。
严重（Error）	服务降级或核心指标超出危险阈值，需尽快处理。
警告（Warning）	指标偏离正常范围但尚未造成严重影响，需关注。
一般（Medium）	指标出现轻微异常或存在潜在风险，对业务暂无明显影响，可在正常工作流程中跟进处理。
提醒（Info）	信息性通知，用于记录系统状态变化或预期内的触发事件，无需立即处理，仅供参考与留存记录。
正常（Ok）	系统恢复正常。连续 N 次检测未产生告警事件时，状态自动恢复为正常。

多级阈值执行逻辑 ：系统按照「致命 → 严重 → 警告」的优先级顺序依次评估。一旦某个级别的条件满足，即使低级别条件也满足，仍只生成对应高级别的事件，不会重复触发。

正常（Ok）恢复逻辑 ：当连续 N 次检测均未触发任何告警条件时，系统自动生成「正常」事件，代表该监控项已从异常状态恢复，可用于触发恢复通知。

数据断档

数据断档（No Data）开关用于处理数据采集中断或上报延迟导致查询结果为空的情况。

状态	说明	备注
关闭（默认）	查询结果为空时，不生成任何事件，监控器保持静默。	默认行为
开启	若在指定检测区间内未收到任何数据（查询结果为空），则生成「数据断档」事件并触发告警通知。 同时支持设置断档数据为0去做阈值对比	用于监测采集链路健康

数据断档判断逻辑

系统判断数据断档的核心依据是：在完整的一个检测区间内，数据库中没有任何符合查询条件的数据点写入。

• 如果开启了数据延迟补偿，系统会在原本应查询的时间窗口基础上，额外向前偏移配置的分钟数，再判断该扩展窗口内是否存在数据；

数据延迟

当数据从采集端上报到存储层存在延迟时（例如 Agent 批量上报、网络抖动、Pipeline 处理耗时等），直接查询当前时间窗口可能导致数据不完整，进而误触发「数据断档」事件或导致阈值判断失准。

开启「数据延迟」后，系统会将告警数据的查询时间整体向前偏移指定分钟数（如 1 分钟），使查询时间窗口落在数据已稳定入库的历史区间，从而避免因数据延迟引起的误报。

示例 ：检测区间为 5 分钟，延迟补偿设置为 1 分钟。原本查询「过去 5 分钟」的数据，实际变为查询「6 分钟前至 1 分钟前」的数据，确保该窗口内的数据已完整写入。

聚合规则

聚合规则定义了当同一监控器在同一时间段内产生多个告警事件时，如何将这些事件归并为一条通知，以降低告警噪音。例如：同一服务上多个接口同时异常时，可聚合为一条告警通知。

内置执行原理详解

检测触发时间

监控器并不是严格按照整点触发，而是在服务初始化时为每个监控器计算一个随机偏移量（jitter），并在此后以固定周期滚动执行。这种机制将大量监控器的执行时间分散开，避免在同一时刻大量查询并发发起，造成数据库查询洪峰。

检测范围校准（数据完整性保障）

时序数据从产生到写入数据库通常存在若干秒至数分钟的延迟（采集、传输、Pipeline 处理）。如果监控器恰好在数据写入完成前执行查询，可能读取到不完整的数据，导致误判。

现行解决方案

系统自动将查询窗口向后退一个固定的安全偏移量（一般为 1~2 分钟），确保查询落在数据已稳定写入的历史时间段内。例如，检测区间为 5 分钟时，实际查询的是距当前时间「6 分钟前至 1 分钟前」的数据，而非最新的 5 分钟。

系统默认开启1分钟偏移，若用户手动关闭了「数据延迟」则将忽略偏移量。

数据断档与数据恢复事件

数据断档和数据恢复是两种特殊类型的监控事件，用于监测数据上报链路的健康状态：

事件类型	触发条件	备注
数据断档事件	当某个检测窗口内查询结果为空（即该时间段内无任何数据写入），且数据断档开关已开启时，系统生成该事件。意味着数据采集或上报链路可能存在故障。	需开启断档开关
数据恢复事件	在发生数据断档后，一旦下一个检测周期内查询到有效数据（即数据重新开始上报），系统自动生成该事件，表示链路已恢复正常。	自动触发

注意 ：在未开启「数据断档」开关的情况下，查询结果为空不会触发任何事件，监控器会静默跳过该周期。

六、常见问题

Q1：为什么配置了规则后，但有时很久才收到告警？

原因可能有以下几种：

• 触发条件中设置了连续 N 次（如 N=3）才告警，需要 3 个周期（3分钟）连续满足条件；
• 数据延迟偏移量较大，导致每次实际检测的数据已是数分钟前的历史数据；

Q2：数据明明存在，为什么触发了「数据断档」告警？

常见原因：

• 数据采集存在较大延迟，导致在查询时窗口内的数据尚未写入。建议开启「数据延迟」并适当增大偏移量；
• 查询条件（生效范围 / 过滤标签）过于严格，实际数据不符合筛选条件。

Q3：多个告警同时触发时，会收到多少条通知？

取决于通知策略的聚合规则配置。未开启聚合时，每个事件独立触发通知；开启聚合后，在聚合窗口内的多个事件合并为一条或几条通知发送。

Q4：如何避免同一问题反复告警（告警疲劳）？

推荐以下配置：

• 在通知策略中设置「重复通知间隔」，例如相同告警每 30 分钟最多通知3次；
• 合理设置触发条件中的连续 N 次，过滤掉瞬时抖动；
• 对低优先级指标开启聚合；
• 利用「屏蔽策略」功能，在维护窗口期间暂停特定监控器的通知。