按业务组与数据源划定范围
每条规则有两个独立的范围：归属的业务组决定谁能改、事件算谁的；数据源列表决定查询打到哪些实例，一条规则可跨多个。
每条规则有两个互不相干的范围：归谁管和查什么。它们在表单的两个不同步骤里设置， 含义完全不同，把两者搞混就是「这个事件怎么跑到别人组里去了」的常见原因。
两个范围，分别在哪儿
| 范围 | 设置位置 | 决定 |
|---|---|---|
| 业务组 | 第 1 步基础配置 → 业务组 | 谁能看到和修改这条规则，以及产生的事件属于哪个组 |
| 数据源 | 第 2 步数据源 → 数据源类型 + 数据源筛选 | 查询发到哪些具体实例上 |
业务组：谁能改，事件算谁的
一条规则只属于一个业务组。这个组决定两件事。
权限。 改一条规则需要它所在业务组的写权限。机制就这一条，没有针对单条规则的权限。
事件归属。 这一条最容易踩：
事件上的业务组，取自规则，不是取自事件所描述的那个对象。
一台属于 Infra Platform 组的机器，被一条挂在 Trading System 组下的规则打中， 产生的事件标的是 Trading System。后面的一切都跟着这个标走：哪些屏蔽规则会命中、 哪些订阅规则能接到、哪个团队在事件列表里看得见。
所以一个团队总收到不属于自己机器的事件时，要改的不是机器归属，而是去看规则挂在哪个组下。
把规则换到另一个组：打开规则，改第 1 步的业务组，保存。想让同一条规则在多个组里都有一份： 在列表里勾选规则，用更多操作 → 克隆到其他业务组。
数据源：查询打到哪些实例上
第 2 步有两个字段。数据源类型选插件——Prometheus Like、Elasticsearch、MySQL 等等。 数据源筛选选这条规则跑在该类型下的哪些已注册实例上。
列表里只会出现你已经注册过至少一个实例的类型。一个只注册了 Prometheus 的环境， 看起来像是产品只支持 Prometheus——那是环境的样子，不是产品的限制。
三种匹配方式
筛选是一组行，每行有一种匹配方式和一个操作符：
| 匹配方式 | 操作符 | 你要填什么 |
|---|---|---|
| 全部数据源 | — | 什么都不填。该类型的所有实例，包括以后新注册的 |
| 精确匹配 | 包含 / 不包含 | 一批具体实例 |
| 模糊匹配 | 包含 / 不包含 | 名称通配符。* 匹配任意个字符，? 只匹配一个字符 |
模糊匹配作用在数据源名称上，所以 prod-* 会命中 prod-beijing 和 prod-shanghai，
也会在哪天有人注册了 prod-tokyo 的时候把它一起收进来。这要么正是你要的，要么正是你不要的，
自己拿主意。
加多行的话，多行之间取交集——每一行都接受，这个实例才算在内。常见写法是一行
模糊匹配 / 包含 / prod-*，再加一行 精确匹配 / 不包含 / <正在维护的那个实例>。
匹配到多个数据源时会怎样
规则会对每个数据源各自独立评估一遍。匹配到三个数据源，就是三条评估循环、三套事件， 判定执行记录里每个周期也是三行。
放宽筛选之前，值得先知道这几条后果：
- 一条本来就慢的查询，变成 N 条慢查询；
- 同一条序列在两个数据源里都有，就产生两条事件，
datasource_id不同——它们不会被去重； - 某个实例挂了只影响它自己那条评估循环，其他照常。
所以「全部数据源」在小环境里是个舒服的默认值，在大环境里是个陷阱。把筛选放宽到一百个 Prometheus 实例，评估负载就悄悄乘了一百。
仅在本业务组生效
第 5 步有个开关叫仅在本业务组生效。它只在 Prometheus 类型的规则上出现， 而且作用范围比名字听起来窄：
如果事件带
ident标签，而这个 ident 对应的机器不属于规则所在的业务组，事件被丢弃。
不带 ident 标签的事件直接放行——这个过滤对它们不生效。
它存在的场景是：几个团队各自把同一条主机监控规则克隆到自己组下。PromQL 查出来的是时序库里 所有机器，但每个团队只该收到自己机器的告警。给每份副本打开这个开关就行，不用改查询。
生效时间窗口
第 5 步剩下的部分决定规则什么时候允许产生事件。
- 立即启用是总开关。关掉就不再产生新事件——恢复事件也算。 一条正在告警的规则被关掉，你就永远等不到那条恢复通知了。想临时静音， 用屏蔽规则。
- 时区决定按哪个时钟读这些窗口。它只影响窗口判定，不影响事件上显示的任何时间。
默认
Local，即服务端所在机器的时区。 - 生效时间是一行或多行「星期几 + 开始时间 + 结束时间」。多行之间是或，命中任意一行即可。 一行都不配就是全天全周生效。
三个容易踩的细节：
- 区间左闭右开：含开始时间、不含结束时间。
00:00 ~ 00:00和00:00 ~ 23:59都表示全天； - 开始时间大于结束时间表示跨天——
22:00 ~ 06:00是合法的一行； - 星期按告警触发那一刻判断。一行「周一，
22:00 ~ 06:00」的含义是 周一 00:00–06:00 加上周一 22:00–24:00，不是「周一晚上到周二早上」。 真要在特定日子做通宵窗口，得拆成两行。
生效范围之外触发的告警会被直接丢弃——不产生事件、不进历史、不通知。 如果你要的是「事件照常记录，只是别叫我」，那是屏蔽规则的「只屏蔽通知」，不是生效时间。
用 API 写范围时的三个坑
用 API、模板导入或脚本建规则时，这三处最容易出错：
datasource_ids 会被忽略。 真正生效的字段是 datasource_queries。默认值——
也就是你在表单里选「全部数据源」时写进去的东西——是：
"datasource_queries": [{"match_type": 2, "op": "in", "values": [0]}]
要按 id 锁定到某一个实例：
"datasource_queries": [{"match_type": 0, "op": "in", "values": [3]}]
生效时间要写复数字段。 enable_stime / enable_etime / enable_days_of_week
是留给老客户端的标量。表单实际写的是数组形式的 enable_stimes / enable_etimes /
enable_days_of_weeks，两者同时存在时以复数的为准：
"enable_stimes": ["09:00"],
"enable_etimes": ["18:00"],
"enable_days_of_weeks": [["1", "2", "3", "4", "5"]]
0 是周日。
顶层 prom_ql 要留空。 prom_ql 非空时，服务端会拿它重建 rule_config，
当成唯一的一条查询，把你写在 rule_config.queries 里的东西全盖掉。