📚 课程目录第3章事件触发机制

3. 事件触发机制：事件源定义与事件总线角色

事件触发机制是自愈剧本的“神经末梢”。Exporter 数据采集链路调优不能只依赖轮询，必须建立基于事件的响应模型。本节聚焦三类事件源的定义方式，以及事件总线（Kafka / RabbitMQ）在链路中的核心角色。

3.1 事件源定义

事件源是触发自愈剧本的原始信号。在可观测性体系中，事件源分为以下三类：

事件类型	数据来源	典型格式	触发条件示例
告警事件	Prometheus Alertmanager、Zabbix、云监控	JSON / Alertmanager Webhook	CPU > 90% 持续 5m → firing
日志事件	Fluentd、Logstash、Filebeat	结构化日志 / JSON lines	ERROR 关键字出现频率 > 阈值
指标阈值事件	Prometheus、VictoriaMetrics、Thanos	PromQL 查询结果 / 时间序列	node_memory_MemAvailable_bytes < 1GB

实践建议： 在自愈剧本中，优先使用告警事件作为触发源，因为 Alertmanager 已内置去重、静默、分组逻辑，可减少剧本的重复执行。日志事件和指标阈值事件更适合作为辅助判断条件。

3.1.1 告警事件定义

告警事件是最成熟的事件源。以 Prometheus Alertmanager 为例，告警事件通过 Webhook 推送至事件总线：

# Alertmanager 配置片段
receivers:
- name: 'event-bus'
  webhook_configs:
  - url: 'http://kafka-producer:8080/alert'
    send_resolved: true
    # 告警事件 JSON 示例
    # {
    #   "status": "firing",
    #   "labels": { "alertname": "HighCPU", "instance": "node1" },
    #   "annotations": { "summary": "CPU > 90%" },
    #   "startsAt": "2025-01-15T10:00:00Z"
    # }

3.1.2 日志事件定义

日志事件通过采集端（如 Filebeat）将日志行转换为事件，并携带元数据：

# Filebeat 配置片段
filebeat.inputs:
- type: log
  paths:
    - /var/log/app/*.log
  processors:
    - add_fields:
        target: event
        fields:
          source: "application"
          severity: "error"

# 输出到 Kafka
output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: "log-events"
  codec.json:
    pretty: false

3.1.3 指标阈值事件定义

指标阈值事件通常由 Prometheus 的 alerting rules 或自定义的阈值检测器生成。在自愈场景中，也可以直接通过 PromQL 查询结果触发：

# Prometheus 告警规则示例
groups:
- name: exporter-thresholds
  rules:
  - alert: ExporterScrapeFailure
    expr: up{job="custom-exporter"} == 0
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Exporter {{ $labels.instance }} 采集失败"

3.2 事件总线与消息队列的角色

事件总线（Event Bus）是事件源与自愈剧本之间的解耦层。Kafka 和 RabbitMQ 是最常用的两种实现，但角色定位不同。

3.3 Kafka 在事件总线中的角色

Kafka 适合作为高吞吐事件流的骨干总线。在 Exporter 自愈场景中，Kafka 承担以下职责：

事件持久化： 所有告警、日志、指标事件写入 Kafka Topic，支持回溯重放。
分区顺序保证： 同一 Exporter 实例的事件按分区有序，避免乱序触发。
多消费者组： 自愈剧本、审计日志、可视化面板可各自独立消费。
削峰填谷： 当 Exporter 批量故障时，Kafka 缓冲事件，防止剧本被击穿。

  关键配置： 自愈场景建议将 Kafka Topic 的 retention.ms 设置为 7 天，min.insync.replicas 设置为 2，确保事件不丢失。

3.4 RabbitMQ 在事件总线中的角色

RabbitMQ 适合路由复杂、低延迟的事件分发。在自愈剧本中，RabbitMQ 的优势在于：

灵活的路由策略： 通过 Direct / Topic / Fanout Exchange 将事件精确分发到不同剧本。
死信队列： 处理失败的事件进入死信队列，便于排查和重试。
优先级队列： 严重告警事件可设置高优先级，优先被剧本消费。
轻量级部署： 适合中小规模集群，运维成本低于 Kafka。

3.5 事件总线选型建议

场景	推荐总线	理由
大规模 Exporter 集群（>1000 实例）	Kafka	高吞吐、持久化、分区顺序
多团队、多剧本、复杂路由	RabbitMQ	灵活 Exchange 绑定、死信队列
事件流需要长期存储和回溯	Kafka	日志留存、Offset 管理
低延迟、快速响应（< 100ms）	RabbitMQ	AMQP 协议、直接投递
混合场景（高吞吐 + 复杂路由）	Kafka + RabbitMQ 桥接	Kafka 做骨干，RabbitMQ 做边缘路由

注意： 不要将事件总线用作数据库。事件在总线中应视为“瞬态”或“短时持久”，长期存储应归档到对象存储或时序数据库。自愈剧本消费事件后，应尽快确认（ACK），避免积压。

3.6 事件触发链路完整性检查清单

事件源侧： 确认告警 Webhook 可达、日志采集无断流、Prometheus 告警规则正确。
总线侧： 验证 Topic / Exchange 存在、消费者组已注册、死信队列配置正确。
消费者侧： 确认剧本服务已订阅、ACK 机制正常、重试策略合理。
监控侧： 对事件总线自身进行监控（吞吐量、积压数、消费者 Lag）。