4. 事件触发机制：事件源接入与过滤去重

事件触发是故障自愈体系的“第一公里”。值班机器人与 Runbook 联动能否及时、准确地启动，完全取决于事件源接入的质量与事件预处理能力。本章聚焦三大主流事件源（Prometheus 告警、日志监控、APM 探针）、Webhook/API 触发方式，以及事件过滤与去重的工程化实践。

4.1 三大核心事件源接入

现代可观测性体系通常由指标（Metrics）、日志（Logs）、链路（Traces）三大支柱构成。对应到事件源，分别由 Prometheus 告警、日志监控平台、APM 探针承担。下表对比了三者的数据特征与接入方式：

4.1.1 Prometheus 告警接入

Prometheus 告警通过 Alertmanager 的 Webhook 配置将告警推送至值班机器人。典型配置如下：

# alertmanager.yml
receivers:
  - name: 'oncall-bot'
    webhook_configs:
      - url: 'http://oncall-bot:8080/webhook/prometheus'
        send_resolved: true
        http_config:
          basic_auth:
            username: 'webhook_user'
            password: 'webhook_pass'

接入后，机器人需解析 Alertmanager 的默认 JSON 结构，提取 alerts[].labels、annotations、status（firing/resolved）等关键字段，并映射为内部事件模型。

4.1.2 日志监控接入

日志监控平台（如 ELK、Loki）通过配置告警规则，在检测到错误日志或特定模式时触发 Webhook。以 Loki 的 Ruler 为例：

# loki-rules.yaml
groups:
  - name: error-log-alerts
    rules:
      - alert: HighErrorRate
        expr: rate({app="nginx"} |= "500" [5m]) > 0.1
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Nginx 5xx 错误率超过 10%"
        webhook: "http://oncall-bot:8080/webhook/loki"

4.1.3 APM 探针接入

APM 探针（如 SkyWalking、Jaeger）通过检测服务响应时间（RT）突变、错误率飙升、调用链断裂等异常，生成事件。以 SkyWalking 为例，其 Webhook 事件体包含：

{
  "scope": "Service",
  "name": "order-service",
  "id0": "order-service-id",
  "id1": "",
  "alarmMessage": "响应时间超过 2000ms 的请求占比 85%",
  "startTime": 1710000000000,
  "alarmTags": ["service", "latency"]
}

APM 事件的优势在于自带调用链上下文，可快速定位故障传播路径，适合与 Runbook 中的链路分析步骤联动。

4.2 Webhook 与 API 触发

除了被动接收事件源推送，值班机器人还应支持主动 API 触发，用于人工介入、定时巡检、第三方系统回调等场景。

4.3 事件过滤与去重

原始事件流中充斥着重复告警、抖动告警、低优先级噪音。若不经处理直接触发 Runbook，将导致资源浪费、告警风暴、甚至误操作。过滤与去重是事件触发前的关键预处理层。

4.3.1 事件过滤策略

• 严重级别过滤： 只保留 critical / warning 级别事件，丢弃 info 级别。
• 来源过滤： 根据事件源标签（如 namespace、cluster）决定是否处理。
• 时间窗口过滤： 同一事件在 T 秒内重复触发，视为抖动，直接丢弃。
• 正则模式过滤： 对事件标题或描述做正则匹配，命中已知误报模式（如“磁盘使用率 80%”但实际为临时峰值）则过滤。

4.3.2 事件去重机制

去重是防止告警风暴的核心手段。推荐使用基于 指纹（Fingerprint） 的去重方案：

1. 指纹生成： 对事件的关键字段（source + labels + title）做 SHA-256 哈希，生成唯一指纹。
2. 缓存比对： 将指纹存入 Redis 或本地 LRU 缓存，设置 TTL（如 30 分钟）。
3. 去重判定： 新事件指纹若已存在于缓存，且状态为 firing，则丢弃；若为 resolved，则清除缓存并允许恢复事件通过。

import hashlib
import redis

r = redis.Redis(host='localhost', port=6379, db=0)

def dedup_event(event):
    fingerprint = hashlib.sha256(
        f"{event['source']}|{event['labels']}|{event['title']}"
        .encode()
    ).hexdigest()

    if event['status'] == 'resolved':
        r.delete(fingerprint)
        return True  # 允许恢复事件通过
    else:
        if r.exists(fingerprint):
            return False  # 重复告警，丢弃
        else:
            r.setex(fingerprint, 1800, '1')  # 30 分钟 TTL
            return True  # 新事件，允许通过

4.4 事件触发整体架构

下图展示了从事件源接入到过滤去重、最终触发 Runbook 的完整链路：

4.5 事件标准化与字段映射

不同事件源的字段命名与结构差异巨大。为实现统一的过滤、去重、路由逻辑，必须在接入层完成事件标准化。推荐的事件标准模型如下：

4.6 本章小结

事件触发机制是故障自愈体系的“传感器网络”。通过标准化接入 Prometheus 告警、日志监控、APM 探针三大事件源，配合 Webhook/API 灵活触发方式，再经过严格的过滤与去重预处理，值班机器人才能获得高质量、低噪音的事件流，为后续 Runbook 匹配与自动化执行奠定可靠基础。