alerts.manage。
规则如何评估
alert 角色每隔 [alert].eval_interval_secs（默认 30 秒）评估一次所有已启用的 scheduled 与 anomaly 规则。real_time 规则在接入路径上匹配，记录到达时就会开启事件。
- 评估器在
now - period_secs到now的窗口内运行query.statement。sql语句由 SQL 引擎执行，promql语句由 PromQL 引擎在now时刻作为即时查询执行。APM 规则则从该窗口的 APM 聚合中读取指标，RUM 规则则从该窗口的 RUM 数据中读取，见 APM 规则和 RUM 规则。 - 评估器把第一行第一列读作数字。结果中没有数字时算作没有数据，怎么处理由
trigger.no_data决定，见恢复条件与没有数据。promql结果的第一列是样本值value，因此由第一条序列决定结果。请先把表达式聚合成一条序列，例如使用sum(...)，或用query.group_by按标签拆分规则，见按列拆分的规则。 - 数字与
trigger比较。thresholds数组非空时，数字改为与每一档阈值比较。 - 条件连续命中
for_periods次评估后，开启一个事件。一条规则同一时间最多有一个活动事件；按列拆分的规则每组最多一个。silence_secs大于 0 时，从该规则上一个事件创建起，经过这么多秒之前不会再开启新事件，即使上一个事件已经解决。 - 满足恢复条件时，评估器会解决处于
open状态的事件。默认的恢复条件是条件第一次不再命中的那次评估。已确认的事件保持已确认，直到用户将其解决。 - 每次评估完成后，评估器把时间写入
last_eval_at，把结果写入last_state。查询失败或超时时，这两个字段保持不变。
scheduled 与 anomaly 规则，调用不会检查数据流或语句是否有效。启用规则前，先运行测试规则。real_time 规则在保存时按下面的限制检查。
请求体
query
第一行中名为
service、host 和 trace_id 的列会丰富事件：新增 service 与 host 标签，并填充 affected_services、host_ids 与 trace_ids。
trigger
anomaly 规则忽略 operator 与 threshold，仍使用 for_periods。带有 thresholds 的规则会忽略 trigger 的 operator、threshold 与 for_periods，但该对象仍是必填项。
thresholds
每一档包含 severity（info、warning、error 或 critical）、operator、threshold 与 for_periods。每一档独立统计连续命中次数。已触发的各档中，最高的严重程度决定事件的严重程度。已开启的事件升到更高的严重程度时，升级会从第一步重新开始。
没有分档时，事件的严重程度依次取规则的 severity、名为 severity 的标签，最后是 warning。对于两者都没有的 anomaly 规则，偏离基线至少 10 倍时为 critical，至少 3 倍时为 error。
anomaly_params
恢复条件与没有数据
trigger.recovery 让事件等数值明确回落后才恢复。否则数值在阈值附近来回时，会反复触发、反复恢复。
trigger.no_data 决定一次评估没有值时算作什么：查询没有返回行或数字，或者按列拆分的规则里某一组不在结果里。
无数据事件有自己的指纹，可以和阈值开的事件同时开着。它带标签
alert.condition = no_data，摘要与规则或这一组的事件相同，通知标题写作 NO DATA · <摘要>。严重程度取规则的 severity，没有时取 severity 标签，再没有是 warning。silence_secs 对它同样生效。值仍然缺着时有人解决了它，数据回来之前不会再开；按列拆分的规则里这一组也不再跟着。real_time 规则不能设 recovery 和 no_data。
按列拆分的规则
带query.group_by 的 scheduled 规则对结果里的每一组分别评估。一组是这些列取值相同的行，列名与结果的列名匹配时不区分大小写。APM、RUM、real_time 或 anomaly 规则带 group_by 时返回 400。
sql语句以 101 行为上限运行，promql语句返回全部序列。每组返回一行，最严重的排在前面。- 组内第一行给出值：除这些列以及
_timestamp、ts、time、timestamp以外的第一个数值列。 - 值与
trigger或thresholds比较，每组各自累计for_periods。 - 触发的组开自己的事件。事件以这一组的取值为标签，摘要是规则名加上这些取值，例如
Errors per host · web-1。silence_secs对每组分别生效。 - 满足恢复条件的组，其
open事件被解决。之前出现过、这次不在结果里的组，这次评估没有值，怎么处理由trigger.no_data决定。 - 有组在触发时
last_state为firing，有组没有值且保持原状态时为no_data，有组命中时为pending，否则为healthy。
group_by 里某个名字的列时，这一轮评估失败，什么都不改变。测试规则会列出每一组。
APM 规则
带query.apm 的规则监控某个 APM 服务或其端点的指标，读取的是 APM 页面使用的同一份聚合。APM 规则必须是 scheduled。调用会把 query.stream 存为 null；query.statement 为空时，会填入 apm:p95 checkout POST /orders 这样的描述。query.language 按原样保存，不起作用。
24 小时以内的窗口读取分钟级聚合，更长的窗口读取小时级聚合。窗口内没有请求时，
request_count、error_count、new_error_groups 和 throughput 读数为 0，其他指标没有读数，因此不会命中阈值。结果的列为 value、service 和 trace_id，因此事件会带上 service 标签、affected_services 中的服务，以及一个样本 trace ID。
RUM 规则
带query.rum 的规则监控某个 RUM 应用的指标，读取方式与 RUM 页面相同。RUM 规则是 scheduled 或 anomaly，一条规则监控 APM 指标或 RUM 指标，不能两者兼有。调用会把 query.stream 存为 null；query.statement 为空时，会填入 rum:lcp_p75 checkout-web /checkout 这样的描述。query.language 按原样保存，不起作用。应用必须存在，否则调用返回 400。
metric 取 session_count、view_count、error_count、error_rate、crash_free_sessions、frustration_rate、failed_request_rate、lcp_p75、inp_p75、cls_p75、ttfb_p75、new_issues 和 regressed_issues 之一。每项指标的含义、单位和所需行数见 RUM 告警。anomaly 规则可以用除 new_issues 和 regressed_issues 之外的全部指标。period_secs 取 60 秒到 6 小时。
窗口内没有行时，计数读数为 0，其他指标没有读数，因此不会命中阈值。结果只有一行，列为 value 和 application。事件开启时，规则还会找出最多三个样本会话，与事件一起保存，见 RUM 告警。
控制台中的操作流程参见告警与事件响应。