4. 异常案例的采集与接入

异常知识库的价值，首先取决于“原料”的质量。如果案例来源单一，知识库就只能覆盖某一类故障；如果接入过程没有统一规范，后续的检索、聚类和复用都会因为字段缺失、时间错乱、语义不一致而失效。本节要解决的核心问题是：把分散在日志系统、工单系统、监控告警、故障报告和用户反馈中的异常信息，稳定、可追溯、可关联地汇入同一个案例池。

一、五类数据源的特征与采集重点

不同数据源的“异常表达方式”差异很大，采集时必须先理解它们的结构，再决定抽取什么。

日志数据是机器视角的原始记录，通常以时间戳、服务名、主机/IP、日志级别、线程、TraceID、异常堆栈等字段出现。它的优势是细节完整、可定位到代码行；劣势是量大、噪声高、同一异常会重复出现成千上万次。采集重点不是“全量搬运”，而是围绕错误级别（ERROR/FATAL）、异常关键字（Timeout、OOM、Connection refused、NullPointerException 等）和调用链标识做过滤与聚合。例如一条典型错误日志：

2024-06-11T03:12:47.318Z ERROR order-service [traceId=9f2c...a71] 
com.mysql.cj.jdbc.exceptions.CommunicationsException: 
Communications link failure - connect timed out after 3000ms
    at com.mysql.cj.jdbc.ConnectionImpl...

采集时应抽取 traceId、服务名、异常类、超时阈值、发生时间，而不是把整段堆栈直接塞进案例标题。

工单数据是人工视角的结构化记录，包含工单号、标题、优先级、创建时间、处理人、处理过程、根因描述和解决方案。它的价值在于“已经被人处理过”，天然带有处置经验；但缺点是描述口语化、字段不统一。采集重点是工单状态（已解决/已关闭）、关联的告警或日志链接、根因分类和解决动作。

监控告警是阈值或规则触发的信号，字段通常包括告警名称、对象、指标、阈值、当前值、触发时间、恢复时间、告警级别。它适合作为“异常发生的入口”，但单条告警信息量少，必须与日志、工单做时间窗关联，才能形成完整案例。

故障报告是事后复盘的产物，结构最完整，包含故障时间线、影响范围、根因、处置过程、改进项。它是高质量案例的主要来源，但数量少、产出慢，采集重点是时间线节点和根因结论。

用户反馈来自客服、社区、问卷或应用内反馈，语言自然但非结构化，例如“下单后一直转圈，最后提示失败”。它往往是最早发现问题的信号，采集重点是反馈时间、涉及功能、用户环境、可复现描述，并尽量关联到同一时段的监控或日志。

二、多源接入的整体链路

把上述五类数据接入知识库，不是简单地把数据堆在一起，而是经过“采集—解析—标准化—关联—入库”的链路。下图展示了这一数据流与关键字段的对应关系。

三、接入规范：字段、时间与关联规则

要让多源数据真正“可合并”，必须约定统一的接入规范。核心包括三部分。

第一，统一案例字段模型。无论数据来自哪一类源，入库时都要映射到同一组字段：案例ID、发生时间（UTC）、来源类型、来源原始ID、影响对象（服务/主机/功能）、异常现象摘要、严重级别、根因分类、处置动作、关联证据链接、采集时间。其中“来源原始ID”用于回溯，“关联证据链接”用于把日志、告警、工单串起来。

第二，统一时间基准。不同系统的时间可能来自不同时区或不同主机时钟。接入时必须统一转换为 UTC，并记录原始时间戳。关联时以“异常发生时间”为中心，设置合理的时间窗，例如告警触发前后各 5 分钟，用于匹配同一时段的日志和工单。

第三，定义关联优先级。当多条数据指向同一异常时，按以下优先级合并：TraceID 精确匹配 > 同一服务+同一时间窗 > 同一工单号 > 同一功能描述。TraceID 是最强关联键，能直接把日志、调用链和告警绑定；没有 TraceID 时，才退化为时间窗和服务名匹配。

四、采集实现中的关键处理

实际采集时，有三类问题最容易导致接入失败或数据质量下降。

重复数据。同一条告警可能被多次推送，同一异常日志可能重复写入。解决方式是生成“去重指纹”，例如用“来源类型+来源原始ID+发生时间”做哈希，入库前先查重。对于日志，还可以按“服务名+异常类+时间窗口”做聚合，把 1000 条相同异常合并为 1 条案例，并记录出现次数。

增量与断点续传。采集不能每次全量拉取。对 API 类数据源，使用“水位线”记录上次采集到的最大时间或最大ID；对日志类数据源，记录文件偏移量或消费位点。采集失败时保留位点，重试成功后从断点继续，避免漏采或重复。

敏感信息与噪声。日志和用户反馈中可能包含手机号、身份证、密码、Token 等敏感信息，接入前必须脱敏。同时要过滤掉无意义的噪声，例如 DEBUG 级别日志、测试环境告警、已知的周期性抖动。过滤规则应可配置，并记录被过滤的数量，便于评估采集覆盖率。

五、一个可参考的接入配置示例

下面给出一个简化的接入配置片段，用于说明字段映射和关联规则如何落地。该示例为教学用途，参数为合理假设值。

source: monitoring-alert
collect:
  mode: webhook
  dedup_key: [alert_name, target, trigger_time]
  watermark_field: trigger_time
map:
  case_id: "ALERT-{alert_id}"
  occur_time: "{trigger_time} | to_utc"
  source_type: "monitoring"
  source_raw_id: "{alert_id}"
  object: "{target}"
  symptom: "{alert_name} 当前值 {current_value} 超过阈值 {threshold}"
  severity: "{level}"
  evidence: "{dashboard_url}"
correlate:
  window: 300s
  priority:
    - trace_id
    - service + time_window
    - ticket_id
    - feature_desc

这段配置表达了三个关键点：用 dedup_key 去重，用 watermark_field 做增量，用 correlate.priority 定义关联顺序。实际落地时，不同数据源只需替换 source 和 map 部分，关联规则可以复用。

六、接入质量的判断依据

采集接入是否合格，不能只看“有没有数据”，而要看四个指标：覆盖率（五类数据源是否都已接入）、完整率（必填字段缺失比例）、关联率（能成功关联到至少一条其他证据的案例占比）、及时性（从异常发生到案例入库的延迟）。例如，若关联率长期低于 60%，说明时间窗或关联键设置不合理；若完整率低于 90%，说明字段映射或采集适配器需要修正。通过这些指标，才能持续改进接入规范，而不是让知识库变成一个只进不出的“数据垃圾场”。