生态里，时序数据的标识，就是一堆标签集合，所以这里的过滤，就 是针对标签做过滤，支持四类操作符：  =：完全匹配，比如 app="clickhouse"  !=：完全不匹配，比如 app!="clickhouse"  =~：正则匹配，比如 app=~"n9e-.*"  !~：正则不匹配，比如 app!~"n9e-.*" 指标名称，通常放到大括号之外，但实际上，指标名称也是一个标签，其标签Key是 app="clickhouse"} 仍然可以达成相同的效果。有时采集的监控数据格式设计的不好，一些本该用 label 的信息，放 到了 metric 名称中了，此时就可以用 __name__ 做一些正则匹配。 Offset 监控系统里，经常会有同环比的需求，比如，当前的值相比一周之前，是否有巨大变化，那怎么 才能获取历史数据呢？可以使用 offset 关键字。 offset 后面跟一个时间段，比如 instant-vector 之间的运算。首先来解释一下各个 运算符的行为。 and vector1 and vector2，其结果是一个由vector1的元素组成的向量，对于这些元素，vector2中 存在着完全匹配的标签集，其他元素被删除。metric的名称和值从左边的向量转移过来。 用于什么场景？先经过 vector1 做过滤得到一批监控数据，可能里边有一些是不想要的，可以 用 and 操作符，再加一个条件，用另一个

单下。监控系统通过 Webhook 发给「全局集成」的告警事件，怎么进入协作空间的呢？通过在协作空 间里配置订阅规则。 订阅规则 订阅规则是一些过滤条件（通过事件标签、属性等），用于匹配告警事件，匹配到的告警事件，自动进入 这个协作空间。 比如：根据标签 来过滤告警事件， 把过滤到的告警事件订阅到“支付”协作空间。在“私有云”协作空 间创建订阅规则，根据标签 来过滤告警事件， 并成故障（incident），最终通知用户的是一个个故 障，大幅降低了打扰性。 不同的告警事件，通常有不同的分发逻辑，比如不同时段不同的分发逻辑：白天用短信通知，晚上用电话 通知，比如对象存储的告警要发给存储团队，物理机故障要发给运维团队。这都可以灵活定义。 也可以配置聚合窗口，比如延迟 120 秒，如果在延迟等待期内，告警自动恢复或被人工处理，则不会发送 该条告警。 的有效手段），其次是团队（团队可以降低人 员管理的负担），其次是个人（最不推荐，难以维护）。FlashDuty 提供了值班表功能，可以做日常排班以 及节假日临时排班： 在 FlashDuty 里，通知的对象不是原始的告警事件，因为原始的告警事件可能会非常多，如上文所述， FlashDuty 会把事件聚合为告警，告警聚合为故障，最终通知的是故障。那具体如何聚合呢？ 告警聚合 事件到告警的聚合比