第二章：运维数据采集与治理——多源数据的“收、洗、存”

大家好，我是老赵。今天咱们聊聊运维数据采集与治理。说实话，很多团队做AI运维，第一步就栽在数据上。你想想看，模型再牛，喂进去的是垃圾，吐出来的只能是更垃圾。我见过太多项目，算法调得飞起，最后发现日志格式不统一、指标缺字段、调用链断了一半……嗯，这活儿真没法干。

所以这一章，咱们就聚焦三个核心问题：怎么把数据收上来？怎么洗干净？怎么存得又快又好？ 我会结合我踩过的坑，给你一套可落地的方案。

2.1 多源数据采集：日志、指标、调用链

运维数据来源五花八门，但核心就三类：日志、指标、调用链。我习惯把它们比作“病历本”、“体检报告”和“家族族谱”。

2.1.1 日志采集：从“大海捞针”到“精准捕捞”

日志是最原始的数据。但问题在于——量太大。我曾经接手过一个电商平台，每天产生50TB的日志，光存储成本就吓死人。

采集方法：

• Filebeat / Fluentd：轻量级Agent，适合容器化环境。我建议优先用Filebeat，资源占用极低。
• Logstash：重量级，适合复杂过滤。但注意，它吃内存，别在业务服务器上跑。
• Kafka：作为缓冲层，解耦生产与消费。这是大流量的标配。

代码示例：Filebeat 配置片段

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/app/*.log
  multiline.pattern: '^\d{4}-\d{2}-\d{2}'
  multiline.negate: true
  multiline.match: after

output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: "app-logs"

2.1.2 指标采集：实时监控的“心跳”

指标数据讲究“高频、低延迟”。Prometheus是当前的事实标准。我个人习惯用Prometheus + node_exporter + 自定义Exporter的组合。

采集要点：

• 系统指标：CPU、内存、磁盘、网络。用node_exporter搞定。
• 应用指标：QPS、延迟、错误率。需要业务代码埋点，暴露/metrics端点。
• 中间件指标：Redis、MySQL、Nginx。各有对应的Exporter。

2.1.3 调用链采集：分布式系统的“X光片”

调用链是排查微服务问题的利器。主流方案是Jaeger或SkyWalking。我偏向SkyWalking，因为它对Java应用几乎零侵入。

采集原理：

• 通过Agent注入，拦截RPC调用（HTTP、gRPC、Dubbo等）。
• 生成Span（跨度），记录调用开始、结束时间、状态。
• 通过Trace ID串联所有Span，形成完整链路。

关键配置：采样率

全量采集成本太高，一般用自适应采样。比如：正常流量采1%，错误流量采100%。

# SkyWalking agent 配置
agent.sample_n_per_3_secs = 10   # 每3秒采样10条
agent.ignore_suffix = .jpg,.css,.js  # 忽略静态资源

2.2 数据清洗：把“脏数据”变成“干净数据”

数据采集上来，第一件事不是存，而是洗。我见过最离谱的情况：日志里时间戳格式不统一，有的用“2024-01-01”，有的用“01/01/2024”。AI模型直接懵了。

清洗三大步骤：

1. 格式标准化：统一时间戳、IP地址、JSON结构。
2. 缺失值处理：指标缺了？用前值填充或插值。日志缺字段？标记为“unknown”。
3. 异常值过滤：比如CPU使用率超过100%？直接丢弃或修正。

代码示例：Logstash 清洗配置

filter {
  # 解析时间戳
  date {
    match => ["timestamp", "ISO8601", "yyyy/MM/dd HH:mm:ss"]
    target => "@timestamp"
  }
  # 移除无用字段
  mutate {
    remove_field => ["beat", "input_type", "offset"]
  }
  # 转换数值类型
  mutate {
    convert => { "response_time" => "float" }
  }
}

2.3 存储策略：分层存储，各取所需

数据存哪里？这个问题没有标准答案。但有一个原则：热数据要快，冷数据要省。

推荐分层架构：

数据层级	存储引擎	保留周期	典型用途
热数据	Elasticsearch / ClickHouse	7天	实时监控、告警、AI实时预测
温数据	Elasticsearch（冷节点）	30天	趋势分析、周报
冷数据	对象存储（S3/MinIO）	永久	历史回溯、模型训练

为什么这么分？

• ES适合全文检索和聚合，但存储成本高。所以热数据用ES，冷数据转存S3。
• ClickHouse适合大规模指标分析，查询速度比ES快10倍以上。我最近在推这个方案。
• 对象存储便宜，但查询慢。适合“归档后几乎不查”的数据。

2.4 知识体系总览：一张图看懂

下面这张SVG图，概括了本章的核心逻辑。从数据源到采集、清洗、存储，再到AI模型消费，一条线串起来。

2.5 本章小结

说白了，数据治理就是“收、洗、存”三个字。但每个字背后都有坑。我建议你从一个小场景开始，比如先搞定Nginx日志的采集和清洗，再逐步扩展到指标和调用链。别想一口吃成胖子。

记住：数据质量决定了AI运维的天花板。数据没治理好，后面的模型再牛也是白搭。