数据采集与预处理：日志采集规范、指标数据清洗、Trace数据标准化、数据质量保障

数据采集与预处理，说白了就是给后续的根因分析「喂好料」。我见过太多团队，算法模型再牛，底层数据一塌糊涂，最后分析出来的结果根本没法看。你想想看，垃圾进，垃圾出，这个道理在可观测性领域尤其残酷。

这一章，我们就来聊聊怎么把日志、指标、Trace 这三类数据收拾得服服帖帖。我个人习惯把这一步叫做「数据基建」，地基打不牢，后面盖什么楼都得塌。

日志采集规范：别让日志变成噪音

日志是最原始、最丰富的数据源，但也是最容易失控的。我在项目中遇到过好几次，线上出故障了，想查日志，结果发现要么没打，要么打了一堆没用的信息，要么格式乱七八糟没法解析。

所以，日志采集规范必须前置。我建议从这几个维度入手：

• 日志级别要统一：ERROR、WARN、INFO、DEBUG，每个级别定义清楚。别搞出什么「FATAL」「CRITICAL」这种自创级别，解析起来头疼。
• 关键字段必须包含：时间戳（精确到毫秒）、服务名、实例ID、请求ID（TraceID）、线程名、类名/方法名、日志内容。缺一个，排查链路就断一截。
• 内容结构化：能用 JSON 就别用纯文本。纯文本日志解析起来费劲，正则写到你怀疑人生。
• 避免敏感信息：密码、身份证、银行卡号，这些不能出现在日志里。我曾经见过一个项目，日志里明文打印了用户密码，那叫一个酸爽。

指标数据清洗：剔除脏数据

指标数据看起来规整，其实坑也不少。比如，某个实例挂了，指标采集器还在疯狂上报 0 值；或者网络抖动，导致某个时间点的数据突然飙升。这些脏数据如果不处理，直接喂给根因分析模型，结果可想而知。

指标数据清洗，我一般分三步走：

1. 去重：同一个指标点，因为采集器重复上报，出现多条相同时间戳的数据。保留第一条，丢弃后续。
2. 异常值过滤：设定合理的上下限阈值。比如 CPU 使用率超过 100% 的，直接丢弃。或者用 3-sigma 原则，把偏离均值太远的数据标记出来。
3. 缺失值填充：时间序列数据难免有空洞。我常用的策略是线性插值，或者用前一个有效值填充。但要注意，填充太多会引入偏差，需要设置一个最大连续缺失阈值。

Trace 数据标准化：让调用链可比较

Trace 数据是根因分析的黄金数据，但前提是它得标准化。不同团队、不同语言、不同框架打出来的 Trace，格式五花八门。如果不做标准化，你根本没法把多个服务的调用链串起来看。

我推荐使用 OpenTelemetry 协议作为标准。它定义了 Trace 的核心数据结构：

• TraceID：全局唯一，贯穿整个请求链路。
• SpanID：每个服务节点内的唯一标识。
• ParentSpanID：父 Span 的 ID，用于构建调用树。
• StartTime / EndTime：Span 的开始和结束时间。
• Attributes：自定义属性，比如 HTTP 方法、状态码、数据库语句等。
• Events：Span 内发生的事件，比如异常、日志。

标准化之后，还需要做一件事——采样策略。全量采集 Trace 数据，存储成本扛不住。我一般用「头部采样 + 尾部采样」结合的方式：

采样策略	适用场景	优点	缺点
头部采样	高流量服务	控制成本，保证代表性	可能漏掉慢请求
尾部采样	低流量或关键服务	保证慢请求被采集	存储成本高
概率采样	通用场景	简单易实现	无法保证关键链路

数据质量保障：持续监控与告警

数据采集规范、清洗、标准化都做了，是不是就万事大吉了？不是。数据质量是会退化的。比如，某个服务升级后，日志格式变了；或者指标采集器配置改了，导致数据缺失。所以，数据质量需要持续监控。

我一般会建立一套数据质量监控体系，核心指标包括：

• 数据完整性：期望采集的数据量与实际采集量的比值。低于 95% 就要告警。
• 数据时效性：数据从产生到入库的延迟。超过 1 分钟就要排查。
• 数据准确性：抽样验证，看数据值是否在合理范围内。
• 数据一致性：不同数据源之间的数据是否对得上。比如，日志中的请求量和指标中的请求量是否一致。

嗯，这里要注意，数据质量监控本身也会产生数据，别让它变成另一个需要监控的系统。我习惯把质量监控指标直接打到现有的可观测性平台里，用同一套告警规则来管理。

知识体系总览

下面这张图，把数据采集与预处理的核心逻辑串起来了。你可以把它当作本章的「地图」：

数据采集与预处理，看起来是脏活累活，但恰恰是根因分析最关键的环节。我见过太多团队，花大价钱买分析工具，结果数据质量一塌糊涂，工具根本跑不起来。所以，别嫌麻烦，把这一步做扎实了，后面的分析才能事半功倍。