第2章运维数据基础

运维数据基础：数据分类与采集存储

大家好，我是老张。今天咱们聊聊运维数据的底子。

做故障根因分析，说白了就是跟数据打交道。数据质量不行，分析结果就是垃圾。我在项目中见过太多团队，工具链搭得挺全，但数据一塌糊涂，最后 RCA 做成了猜谜游戏。

所以，这一章我们先打好基础。把运维数据的分类、采集、存储讲清楚。嗯，这里要注意，数据质量对 RCA 的影响，我会重点说。

运维数据的四大分类

我个人习惯把运维数据分成四类：指标、日志、链路、事件。这四类数据，就像人的五官，各司其职。

1. 指标（Metrics）

指标是数字化的，说白了就是“某个时间点的数值”。比如 CPU 使用率 85%，QPS 2000，内存占用 4GB。

指标的特点是：轻量、高频、可聚合。你想想看，一台机器每秒产生几百个指标，但每个指标就几个字节。Prometheus 就是干这个的。

指标适合回答“系统现在怎么样？”这类问题。比如“过去5分钟，接口延迟是不是飙升了？”

我在项目中遇到过，有一次线上告警说 CPU 飙到 95%，但业务没受影响。后来发现是监控采集频率太高，把 CPU 打满了。嗯，这就是指标采集的坑。

2. 日志（Logs）

日志是文本化的，记录的是“发生了什么”。比如一条错误日志：“2025-01-15 10:23:45 ERROR - 数据库连接超时”。

日志的特点是：信息丰富、结构多样、体积大。一条日志可能几百字节，但一天下来能攒几个 TB。

ELK 栈（Elasticsearch、Logstash、Kibana）是处理日志的经典方案。我个人习惯把日志按级别分类：DEBUG、INFO、WARN、ERROR。做 RCA 时，ERROR 日志是重点，但 WARN 日志也别放过。

我曾经排查过一个诡异故障：服务间歇性超时，ERROR 日志里啥也没有。后来翻了 WARN 日志，发现是连接池快要满了，触发了回收机制。WARN 日志里藏着真相。

3. 链路（Traces）

链路追踪，记录的是“一个请求经过了哪些服务”。比如用户下单，请求先到网关，再到订单服务，再到支付服务，最后到数据库。

链路数据的特点是：关联性强、维度多、采样率高。Jaeger 是链路追踪的标杆工具。

为什么需要链路？因为微服务架构下，一个故障可能跨多个服务。指标告诉你“接口慢了”，日志告诉你“某个服务报错了”，但链路能告诉你“慢在哪一步”。

链路数据是 RCA 的“破案地图”。没有链路，你就像在黑夜里找东西。

4. 事件（Events）

事件是离散的、有明确时间点的“事情”。比如“服务器重启”、“配置变更”、“发布上线”、“告警触发”。

事件数据的特点是：稀疏、语义明确、上下文重要。事件通常不是系统自动产生的，而是由人或工具触发的。

做 RCA 时，事件数据经常被忽略。但我告诉你，很多故障的根因就藏在事件里。比如“发布后 3 分钟，错误率飙升”，那根因大概率就是这次发布。

我曾经遇到一个案例：故障持续了 2 小时，所有人都在查代码、查配置。最后发现，是运维同事在故障前 10 分钟改了一个防火墙规则。这个“事件”没人记录，导致大家白忙活半天。

数据采集与存储方案

数据分类清楚了，接下来就是怎么采、怎么存。我挑三个主流方案讲：Prometheus、ELK、Jaeger。

Prometheus：指标采集与存储

Prometheus 是 CNCF 的毕业项目，也是指标监控的事实标准。它的核心是“拉模式”：Prometheus Server 定期去目标 exporter 拉取指标数据。

# prometheus.yml 配置示例
scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']

Prometheus 的存储是时序数据库，数据模型是：metric_name + labels + timestamp + value。比如：

http_requests_total{method="GET", endpoint="/api/v1/users"} 1024 @ 1705300000

我个人习惯用 PromQL 做查询。比如查过去 5 分钟的平均 CPU 使用率：

avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100

Prometheus 的存储有局限性：它不适合存长期历史数据。我建议保留 15-30 天的数据，更早的数据可以转存到 Thanos 或 VictoriaMetrics。

ELK：日志采集与存储

ELK 是 Elasticsearch、Logstash、Kibana 的缩写。现在也有 Filebeat 替代 Logstash 做轻量采集。

日志采集的流程是：Filebeat 采集日志文件 -> 发送到 Logstash 或直接到 Elasticsearch -> Kibana 做可视化。

# filebeat.yml 配置示例
filebeat.inputs:
  - type: log
    paths:
      - /var/log/app/*.log

output.elasticsearch:
  hosts: ["localhost:9200"]

Elasticsearch 的存储是倒排索引，适合全文搜索。做 RCA 时，我经常用 Kibana 的搜索功能，比如搜“ERROR”关键字，再按时间聚合。

日志存储要注意：别把所有日志都存进去。我建议只存 WARN 及以上级别的日志，DEBUG 日志本地保留即可。否则 Elasticsearch 集群会撑爆。

Jaeger：链路采集与存储

Jaeger 是 Uber 开源的链路追踪系统，也是 CNCF 项目。它的核心概念是 Span（跨度）和 Trace（追踪）。

一个 Trace 由多个 Span 组成，每个 Span 代表一个服务调用。比如：

TraceID: abc123
Span1: 网关 -> 订单服务 (耗时 50ms)
Span2: 订单服务 -> 支付服务 (耗时 30ms)
Span3: 支付服务 -> 数据库 (耗时 20ms)

Jaeger 的存储后端支持 Elasticsearch、Cassandra、Kafka 等。我个人习惯用 Elasticsearch 做存储，这样链路数据和日志数据可以统一查询。

链路数据一定要做采样！全量采集的话，数据量是日志的 10 倍以上。我建议生产环境采样率设为 1%-10%，错误链路可以全量采集。

数据质量对 RCA 的影响

数据质量不行，RCA 就是空中楼阁。我总结了几点常见问题：

数据质量问题	对 RCA 的影响	我的建议
数据缺失	无法定位故障时间点	设置数据完整性告警
数据延迟	故障时间线错乱	监控采集延迟，超过 1 分钟告警
数据不一致	指标和日志对不上	统一时间戳格式，使用 NTP 同步
数据冗余	存储成本高，查询慢	设置合理的保留周期和采样率

数据质量的核心是：完整、及时、一致、准确。这四个维度缺一不可。

我曾经遇到一个案例：某次故障，指标显示 CPU 正常，但日志里全是超时错误。后来发现，指标采集的机器和日志采集的机器时间差了 5 分钟。时间不一致，导致 RCA 完全跑偏。

所以，我建议团队在搭建数据平台时，先把数据质量监控做起来。别等到故障了才发现数据有问题。

本章知识体系

下面这张图，是我梳理的本章知识体系。你可以看到四大数据分类、三大采集存储方案，以及数据质量对 RCA 的影响路径。

这张图的核心逻辑是：四大数据分类 -> 各自采集方案 -> 各自存储方案 -> 数据质量保障 -> RCA。缺一环都不行。

好了，这一章就到这里。数据是 RCA 的基石，下一章我们会深入讲指标数据的采集与 PromQL 实战。嗯，到时候见。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

运维数据基础：数据分类与采集存储

运维数据的四大分类

1. 指标（Metrics）

2. 日志（Logs）

3. 链路（Traces）

4. 事件（Events）

数据采集与存储方案

Prometheus：指标采集与存储

ELK：日志采集与存储

Jaeger：链路采集与存储

数据质量对 RCA 的影响

本章知识体系