3、事件源识别与分类：常见事件源与事件分类

事件触发引擎的核心能力在于对异构事件源的统一接入与标准化处理。在生产环境中，告警事件可能来自监控系统、云平台、日志分析等多个维度。本章将系统梳理常见事件源的接入特征与事件分类体系，为后续的事件过滤、去重与路由提供基础。

3.1 常见事件源概述

事件触发引擎需要适配不同协议、不同数据格式的事件源。下表对比了四种主流事件源的接入方式与数据特征：

3.2 事件源接入架构

下图展示了事件触发引擎与四种常见事件源的逻辑连接关系，以及事件数据在引擎内部的流转路径：

3.3 事件分类体系

事件触发引擎根据事件产生的机制与业务含义，将事件划分为三大核心类别。每种分类对应不同的处理逻辑与自愈策略：

• 阈值告警（Threshold Alert）：基于固定或动态阈值触发，如 CPU 使用率 > 90%、磁盘剩余空间 < 5GB。这类事件规则明确，适合直接匹配自愈剧本。
• 异常检测（Anomaly Detection）：基于历史基线或机器学习模型识别，如流量突增、响应时间偏离。这类事件需要结合上下文进行根因分析。
• 状态变更（State Change）：由资源或服务的状态转换触发，如进程 Down、端口 Offline、Pod CrashLoopBackOff。这类事件通常需要快速响应与恢复。

3.4 事件分类对比

下表从触发机制、数据特征、典型场景与自愈策略四个维度，对三类事件进行详细对比：

3.5 事件分类在引擎中的映射

事件触发引擎在接收到统一事件模型后，会根据事件元数据中的 event_type 字段进行自动分类。以下是一个典型的事件分类映射配置示例：

# event_classification_rules.yaml
classification:
  - name: "threshold_alert"
    match:
      event_type: "threshold"
      severity: ["critical", "warning"]
    action: "direct_remediation"

  - name: "anomaly_detection"
    match:
      event_type: "anomaly"
      confidence: < 0.8
    action: "diagnosis_first"

  - name: "state_change"
    match:
      event_type: "state"
      from_state: "running"
      to_state: "down"
    action: "immediate_restart"

3.6 事件源与分类的关联矩阵

不同事件源产生的事件类型分布存在差异。理解这种关联关系，有助于在引擎中配置更精准的过滤与路由策略：

3.7 事件源接入最佳实践

在搭建事件触发引擎时，针对不同事件源与事件分类，建议遵循以下实践原则：

1. 统一事件模型先行：在接入任何事件源之前，先定义内部统一事件模型（UEM），包含 source、event_type、severity、timestamp、payload 等核心字段。
2. Webhook 优先：对于支持 Webhook 的事件源（如 Prometheus Alertmanager、云监控），优先使用推送模式，减少引擎的轮询开销。
3. 日志系统适配：日志系统的事件通常是非结构化文本，建议在接入层增加日志解析器，将关键字段提取到统一事件模型中。
4. 分类标签注入：在事件接入层自动注入 event_class 标签，便于后续规则引擎快速路由。
5. 灰度接入：新事件源接入时，先设置为“观察模式”，不触发实际自愈动作，待数据验证通过后再启用。