AIOps 数据采集：日志/指标/链路数据的整合与标准化

AIOps的核心是数据驱动的智能决策 ，而日志、指标、链路三类核心运维数据的全量采集、统一整合、标准化治理 是AIOps落地的基础前提。三类数据从不同维度刻画系统运行状态：指标反映系统实时性能，日志记录系统行为细节，链路追踪分布式调用路径，三者孤立则无法实现全维度故障定位与根因分析，整合与标准化 的核心目标就是打破数据孤岛，实现"一个故障、全量数据、关联分析"，为后续特征工程和智能分析提供高质量、结构化、可关联的统一数据底座。

本文围绕AIOps落地中日志、指标、链路数据的采集痛点，从采集架构设计、分类型采集方案、统一整合方法、标准化规范、工程落地要点五个维度展开，兼顾技术完整性和落地实用性，同时提供企业级的采集工具选型和标准化模板，适配云原生、微服务、分布式等主流IT架构。

一、AIOps 三类核心数据的特征与采集痛点

在设计采集和标准化方案前，需先明确日志、指标、链路数据的核心特征和落地痛点，针对性解决采集不全面、格式不统一、关联无标识、存储不匹配等问题。

1. 三类核心数据的核心特征对比

数据类型	核心定义	数据特征	典型来源	核心价值	采集要求
指标（Metric）	系统/应用运行的数值化、时序化性能数据	时序性强、结构化、高写入、低存储、实时性要求高	Prometheus、Zabbix、Node Exporter、中间件/数据库内置监控、业务埋点	实时性能监控、异常检测、容量规划、趋势预测	秒级采集、低延迟、高可靠、按维度聚合
日志（Log）	系统/应用运行的行为记录文本	非结构化/半结构化、高吞吐、多格式、含关键上下文	应用日志、系统日志、容器日志、安全日志、审计日志	故障溯源、根因定位、行为审计、安全分析	全量采集、断点续传、按关键字过滤、低侵入
链路（Trace）	分布式系统中一次请求的全路径调用记录	结构化、带调用拓扑、含耗时/状态、关联多节点	OpenTelemetry、SkyWalking、Pinpoint、Jaeger	分布式故障定位、链路性能优化、调用关系分析	全链路埋点、低采样率（高吞吐场景）、关联请求ID

2. 企业级采集核心痛点

数据孤岛严重：指标、日志、链路数据分别由不同工具采集、存储在不同介质，无统一关联标识（如请求ID、Trace ID），无法实现联合分析；
格式杂乱无章：日志无统一模板，指标维度命名不规范，链路埋点字段不一致，同一类数据在不同系统中格式差异大；
采集侵入性高：传统埋点方式需修改业务代码，链路采集采样率过高导致系统性能损耗，日志全量采集占用大量磁盘和网络资源；
实时性不足：部分日志采集采用定时拉取方式，延迟达分钟级，无法满足AIOps实时异常检测和故障定位需求；
元数据缺失：数据缺少统一的业务标签、资产标签、拓扑标签，无法实现按业务/集群/节点的维度分析；
存储与采集不匹配：将非结构化日志存入关系型数据库，将高吞吐指标存入普通文件，导致查询效率低、存储成本高。

二、AIOps 数据采集整体架构设计

针对三类数据的特征和采集痛点，设计**"统一采集层-传输层-治理层-存储层"** 的四层分布式采集架构，核心遵循**"采集解耦、统一传输、标准化治理、分级存储、全局关联"** 原则，适配云原生、微服务、物理机/虚拟机混合部署的企业级场景，同时支持无代理采集、轻量级Agent采集、协议对接多种方式，兼顾采集全面性和系统低侵入性。

1. 四层采集架构核心设计

存储层-分级适配
治理层-整合+标准化
统一传输层-高可靠
统一采集层-多方式适配
全量数据源
物理机/虚拟机
容器/K8s集群
中间件/数据库
微服务/业务应用
第三方平台/云服务
轻量级Agent

Filebeat/OTel Agent/Node Exporter
无代理采集

SSH/SNMP/API拉取
协议对接采集

Prometheus API/Syslog/HTTP
埋点采集

OTel SDK/自定义埋点
消息队列

Kafka/RabbitMQ
传输协议

gRPC/HTTP/FLB
流量控制

限流/削峰/压缩
断点续传

本地缓存/失败重发
数据清洗

去重/去噪声/补全
统一标准化

字段/格式/单位/命名
全局关联

打标Trace ID/Request ID/资产ID
标签融合

业务/集群/拓扑标签打标
指标存储

Prometheus/VictoriaMetrics/TDengine
日志存储

Elasticsearch/ClickHouse
链路存储

Elasticsearch/Tempo/Pinot
元数据存储

MySQL/MongoDB/ETCD
冷数据归档

2. 架构核心设计原则

采集与业务解耦：采集逻辑通过独立Agent/无代理方式实现，无侵入/低侵入式部署，避免修改业务代码影响系统稳定性；
统一传输中间件：所有数据通过Kafka等消息队列统一传输，实现削峰填谷、断点续传，解决高吞吐场景下的采集丢数问题；
标准化前置：在治理层完成统一标准化和全局关联，而非在存储和分析层，减少后续重复处理成本；
分级存储适配：根据三类数据的特征选择专属存储引擎，兼顾查询效率和存储成本，热数据存专属引擎，冷数据归档至对象存储；
全局唯一标识 ：为所有数据打上Trace ID/Request ID 全局关联标识，实现"一次请求、全链路数据关联"；
弹性扩展：采集层、传输层、治理层均采用分布式部署，支持横向扩展，适配企业业务规模的持续增长；
低侵入性 ：链路采集默认采用低采样率（如1%） ，日志采集支持按关键字过滤/按大小切割 ，指标采集采用增量拉取，将系统性能损耗控制在5%以内。

三、日志/指标/链路分类型采集方案

基于四层采集架构，针对日志、指标、链路三类数据的特征，设计专属采集方案 ，明确核心采集工具、部署方式、关键配置，兼顾采集全面性、实时性、低侵入性，同时为后续整合和标准化打下基础。

1. 指标数据采集方案（时序化、结构化采集）

指标数据是AIOps实时监控的核心，采集核心是**"全维度、秒级、低延迟、按维度聚合"，覆盖基础资源、中间件、数据库、业务四大类指标，采用"Agent拉取+协议对接"** 组合方式，核心工具基于Prometheus生态，适配云原生和传统架构。

核心采集工具

基础资源采集：Node Exporter （CPU/内存/磁盘/网络）、cadvisor（容器指标）；
中间件/数据库采集：Prometheus Exporter（Redis/MongoDB/MySQL/Kafka Exporter）；
业务指标采集：OpenTelemetry SDK（自定义业务埋点，如QPS/响应时间/成功率）；
统一聚合：Prometheus （指标拉取、聚合、存储）、VictoriaMetrics（海量指标存储扩容）；
第三方对接：Prometheus API（拉取云平台/第三方监控指标）。

核心部署方式

Agent侧部署 ：将Node Exporter/cadvisor/各类Exporter部署在目标服务器/容器中，以DaemonSet方式在K8s集群中部署，确保每个节点都有采集Agent；
服务端拉取 ：Prometheus服务端通过HTTP API 定时拉取各Agent的指标数据，拉取间隔默认15s（核心指标可调整为5s）；
维度打标 ：为所有指标打上instance（实例）、job（任务）、cluster（集群）、namespace（命名空间） 基础维度标签，后续在治理层补充业务标签。

关键配置要点

增量采集：仅拉取指标的变化值，减少网络传输量；
维度聚合：在采集层对相同维度的指标进行聚合，避免重复存储；
指标过滤：过滤无用指标（如系统无关的临时指标），减少存储压力；
高可用：Prometheus采用主从部署 ，搭配Thanos实现指标数据的长期存储和多集群聚合。

2. 日志数据采集方案（全量、实时、低侵入采集）

日志数据是故障溯源的核心，采集核心是**"全量采集、断点续传、实时性、按关键字过滤"，覆盖系统日志、应用日志、容器日志、安全日志，采用"轻量级Agent推送"** 方式，核心工具基于ELK/EFK生态，支持非结构化/半结构化日志采集。

核心采集工具

日志采集Agent：Filebeat （轻量级、低资源占用、断点续传）、Fluent Bit（容器场景首选，轻量化）；
日志清洗/转发：Logstash （复杂清洗）、Fluentd（云原生场景转发）；
统一存储：Elasticsearch （全文检索、实时分析）、ClickHouse（海量日志统计分析）；
可视化：Kibana（日志查询、可视化）。

核心部署方式

Agent侧部署 ：Filebeat/Fluent Bit以DaemonSet 方式部署在K8s集群，以系统服务方式部署在物理机/虚拟机，直接采集目标日志文件；
实时推送 ：Agent采用行尾监听 方式，实时采集新增日志，通过Kafka推送给治理层，采集延迟≤1s；
本地缓存 ：Agent支持本地磁盘缓存（默认512MB），当传输层故障时，将日志缓存至本地，故障恢复后断点续传，避免丢数；

关键配置要点

日志过滤：通过正则表达式过滤无用日志（如调试日志、重复日志），仅采集ERROR/WARN/INFO核心级别日志；
日志切割：配置日志按大小/按时间切割（如1GB/24h），避免单日志文件过大导致采集卡顿；
格式识别：Agent自动识别JSON/文本格式日志，对非结构化文本日志做初步结构化处理（提取时间/级别/内容）；
资源限制：将Filebeat/Fluent Bit的CPU/内存占用限制在1核/512MB以内，避免影响业务系统；
多路径采集：支持同时采集多个日志文件路径，适配一个节点多应用的部署场景。

3. 链路数据采集方案（全链路、低侵入、关联采集）

链路数据是分布式系统故障定位的核心，采集核心是**"全链路埋点、低采样率、全局Trace ID、调用拓扑采集"，覆盖微服务、分布式应用的全链路调用，采用"无侵入Agent+轻量级SDK埋点"** 组合方式，核心工具基于OpenTelemetry生态，实现跨语言、跨框架的统一链路采集。

核心采集工具

无侵入采集：OpenTelemetry Agent（自动埋点，支持Java/Go/Python等主流语言，无需修改业务代码）；
自定义埋点：OpenTelemetry SDK（业务自定义埋点，如关键业务步骤耗时）；
链路收集/存储：Jaeger/Tempo （链路收集、存储、可视化）、Elasticsearch（链路数据全文检索）；
调用拓扑分析：SkyWalking（链路拓扑自动生成、性能分析）。

核心部署方式

无侵入Agent挂载 ：在K8s/容器中，通过sidecar 方式将OpenTelemetry Agent挂载至业务容器；在物理机/虚拟机中，通过JVM参数挂载Agent，实现自动埋点，无需修改业务代码；
低采样率采集 ：默认采用1%采样率采集链路数据，高吞吐核心业务可调整为5%，非核心业务采用0.1%，将系统性能损耗控制在3%以内；
全局Trace ID生成 ：由入口服务（如网关）生成全局唯一Trace ID，并在全链路调用中传递，为所有链路数据打上Trace ID标识；
调用数据采集 ：采集每个调用节点的耗时、状态、请求参数、响应结果 ，以及节点间的调用关系、拓扑结构。

关键配置要点

采样率动态调整：支持根据请求量/响应时间/错误率动态调整采样率，如故障时自动将采样率提升至100%，实现故障全链路数据采集；
链路过滤：过滤无用链路（如健康检查、内部心跳调用），减少存储压力；
上下文传递：支持HTTP/gRPC/Kafka等主流协议的Trace ID上下文传递，确保跨服务、跨中间件的链路连续性；
拓扑自动生成：通过链路数据自动生成服务调用拓扑图，实时更新服务间的调用关系，为根因定位提供拓扑依据；
与日志/指标关联：将Trace ID传递至日志和指标采集层，为日志和指标数据打上Trace ID，实现三者关联。

四、日志/指标/链路数据统一整合方法

整合是打破数据孤岛的核心，核心是**"全局唯一标识关联+标签融合+时序对齐"，将日志、指标、链路三类数据通过 Trace ID/Request ID/Instance ID** 全局标识关联起来，同时融合业务标签、资产标签、拓扑标签，实现"一次请求、全链路数据关联，一个故障、全维度数据分析"。

1. 核心整合维度：三大全局唯一标识

为所有数据打上全局唯一标识 ，是实现三类数据整合的基础，标识需在采集层生成、传输层传递、治理层统一，确保全链路一致性，核心三大标识：

Trace ID/Request ID ：全局核心关联标识，由入口服务（网关/负载均衡）生成，为一次请求的全链路数据打上统一标识，实现"一次请求→日志+指标+链路"全关联；
Instance ID/Node ID ：资产关联标识，为每个服务器/容器/应用实例分配唯一ID，实现"一个节点→该节点的所有日志+指标+链路"关联；
Business ID/Service ID ：业务关联标识，为每个业务/微服务分配唯一ID，实现"一个业务→该业务的所有日志+指标+链路"关联。

标识传递原则

入口生成：Trace ID/Request ID由业务入口层统一生成，避免多节点生成导致的标识不一致；
全链路传递：通过请求头/上下文/消息体将标识传递至所有下游服务、中间件、数据库，确保全链路连续性；
强制打标：采集层在采集数据时，必须检查标识是否存在，缺失则补全（如补全Instance ID），无法补全则标记为"无标识数据"并单独存储。

2. 核心整合方法：四类关联融合

基于三大全局唯一标识，在治理层实现四类关联融合，将孤立的日志、指标、链路数据整合为统一的数据集，为后续智能分析提供关联依据：

（1）全链路请求关联：Trace ID/Request ID 核心关联

这是最核心的整合方式，实现**"一次请求的全链路数据关联"**：

链路数据：天生携带Trace ID，记录一次请求的全链路调用路径和各节点耗时；
日志数据：在日志中打印Trace ID，采集层提取日志中的Trace ID并打标，实现日志与链路的关联；
指标数据：按Trace ID/Request ID聚合业务指标（如该请求的响应时间、QPS），实现指标与链路的关联；
整合效果：通过一个Trace ID，可查询到该请求的全链路调用记录、所有节点的日志、相关的性能指标，实现"一次请求、全量数据溯源"。

（2）资产节点关联：Instance ID/Node ID 物理关联

实现**"一个服务器/容器/应用实例的所有数据关联"**：

为每个服务器/容器/应用实例分配唯一的Instance ID，采集层为该实例的所有日志、指标、链路数据打上该ID；
整合效果：通过一个Instance ID，可查询到该节点的所有系统指标、应用日志、链路调用记录，实现"一个节点、全状态分析"，快速定位节点级故障。

（3）业务服务关联：Business ID/Service ID 业务关联

实现**"一个业务/微服务的所有数据关联"**，适配企业按业务维度的运维管理需求：

为每个业务线/微服务分配唯一的Business ID/Service ID，采集层为该业务的所有日志、指标、链路数据打上该ID；
整合效果：通过一个Business ID，可查询到该业务的整体性能指标、所有相关应用的日志、全链路调用拓扑，实现"业务级全景监控"。

（4）时序对齐关联：时间戳时序关联

所有数据均采用UTC+8 毫秒级时间戳进行时序对齐，实现**"同一时间点的所有数据关联"**：

采集层为所有数据打上毫秒级时间戳，确保时间精度一致；
治理层按时间戳将同一时刻的指标、日志、链路数据关联，实现"时间维度的全景分析"，如查询"某一时刻系统CPU飙升时的所有日志和链路调用记录"。

3. 整合落地工具与流程

核心整合工具

全局标识生成：API网关 （如Nginx/Zuul/Spring Cloud Gateway）、OpenTelemetry Agent；
数据打标/融合：Logstash/Fluentd （日志打标）、Prometheus Relabel （指标打标）、Flink/Spark（实时数据融合）；
关联存储：Elasticsearch （全量数据关联存储、全文检索）、ClickHouse（海量数据关联统计）；

核心整合流程

网关/入口服务
生成Trace ID/Request ID
传递至下游服务/中间件/数据库
日志/指标/链路采集层
采集数据并提取标识
为数据打上Trace ID/Instance ID/Business ID+时间戳
通过Kafka传输至治理层
治理层
按标识+时间戳实现三类数据关联
存入Elasticsearch/专属存储引擎
AIOps智能分析层联合查询

五、日志/指标/链路数据标准化规范

标准化是AIOps数据治理的核心，核心是**"制定企业级统一标准，实现数据格式、字段、命名、单位、标签的全统一"，解决"格式杂乱、字段不一致、命名不规范"问题，为后续特征工程和智能分析提供结构化、可复用、可关联**的标准数据。

标准化需遵循**"通用性、扩展性、落地性"** 原则，先制定基础核心标准 （必选字段/格式），再预留扩展字段 （适配各业务线的个性化需求），同时成立企业级数据标准委员会，负责标准的制定、更新和落地监督，确保标准在全公司范围内的统一执行。

1. 标准化核心框架："必选字段+扩展字段+标签体系"

所有数据均采用**"JSON结构化格式"** 存储，核心由必选字段、扩展字段、标签体系三部分组成：

必选字段：企业级统一要求，所有数据必须包含，确保基础一致性（如trace_id、instance_id、timestamp、data_type）；
扩展字段：各业务线/系统的个性化字段，在基础标准上扩展，确保灵活性（如业务自定义的order_id、user_id）；
标签体系 ：企业级统一标签，分为基础标签、业务标签、拓扑标签，所有数据必须打标，实现多维度分析。

2. 分类型标准化规范（企业级可直接落地）

（1）指标数据标准化规范（时序结构化）

指标数据核心采用Prometheus指标格式 为基础，统一指标命名、维度命名、单位、数据类型 ，必选字段包含指标名、维度、值、时间戳、全局标识 ，所有指标均为数值型，单位统一规范。

必选字段

字段名	字段类型	字段说明	示例	必选
metric_name	string	指标名，小写+下划线，统一命名规范	cpu_util、mem_used、mysql_qps	是
metric_value	float/int	指标值，数值型	80.5、1024、5000	是
timestamp	long	毫秒级时间戳（UTC+8）	1714521600000	是
trace_id	string	全局链路标识，无则填null	f8a2b9c3-1d4e-5f67-890a-b1c2d3e4f567	否
instance_id	string	资产实例标识	node-01、container-nginx-02	是
business_id	string	业务标识	e-commerce-trade、finance-pay	是
data_type	string	数据类型，固定为metric	metric	是

统一规范

指标命名：小写字母+下划线，格式为**"模块_指标含义"**（如cpu_util、redis_connected_clients）；
维度命名：统一为instance、job、cluster、namespace、business，避免自定义维度；
单位统一：CPU/内存使用率（%）、内存/磁盘大小（MB/GB）、网络带宽（Mbps）、耗时（ms）、QPS/TPS（个/秒）；
数据类型：使用率（浮点型，保留1位小数）、计数型（整型）、耗时（浮点型，保留2位小数）。

（2）日志数据标准化规范（结构化）

日志数据核心实现**"非结构化→结构化"** 转换，统一日志级别、时间格式、必选字段 ，消除不同系统的日志格式差异，必选字段包含日志级别、时间戳、全局标识、日志内容，扩展字段适配各业务的个性化需求。

必选字段（JSON格式）

JSON 复制代码

{
  "log_level": "ERROR/WARN/INFO/DEBUG", // 日志级别，统一大写
  "timestamp": 1714521600000, // 毫秒级时间戳（UTC+8）
  "trace_id": "f8a2b9c3-1d4e-5f67-890a-b1c2d3e4f567", // 全局链路标识，无则填null
  "request_id": "req-123456789", // 请求标识，无则填null
  "instance_id": "node-01", // 资产实例标识
  "business_id": "e-commerce-trade", // 业务标识
  "service_name": "order-service", // 服务名
  "log_content": "数据库连接超时，连接数：1000", // 日志内容，纯文本
  "stack_trace": "java.sql.SQLTimeoutException: Timeout", // 异常堆栈，无则填null
  "data_type": "log" // 数据类型，固定为log
}

统一规范

日志级别：仅保留ERROR/WARN/INFO三级，过滤DEBUG级日志（特殊场景可单独配置）；
时间格式：统一为毫秒级时间戳（UTC+8），避免使用字符串时间（如2024-05-01 12:00:00）；
内容规范：日志内容需简洁、明确，包含"错误原因、关键参数、状态值"，避免无意义的冗余内容；
异常堆栈：单独存储stack_trace字段，便于故障溯源和关键字检索；
格式转换：所有非结构化日志通过正则表达式/Logstash Grok转换为上述JSON结构化格式。

（3）链路数据标准化规范（全链路结构化）

链路数据核心基于OpenTelemetry标准 ，统一调用节点、耗时、状态、全局标识 ，必选字段包含Trace ID/Span ID、调用关系、耗时、状态，确保跨服务、跨框架的链路数据格式一致。

必选字段（JSON格式）

JSON 复制代码

{
  "trace_id": "f8a2b9c3-1d4e-5f67-890a-b1c2d3e4f567", // 全局Trace ID，唯一
  "span_id": "s12345678", // 节点Span ID，唯一
  "parent_span_id": "s87654321", // 父节点Span ID，根节点填null
  "service_name": "order-service", // 当前服务名
  "parent_service": "gateway-service", // 父服务名，根节点填null
  "operation_name": "createOrder", // 操作名（接口/方法名）
  "start_time": 1714521600000, // 调用开始时间戳（毫秒）
  "end_time": 1714521600100, // 调用结束时间戳（毫秒）
  "duration": 100, // 调用耗时（ms）
  "status": "SUCCESS/ERROR", // 调用状态，统一大写
  "error_msg": "数据库连接超时", // 错误信息，成功则填null
  "instance_id": "node-01", // 当前实例标识
  "business_id": "e-commerce-trade", // 业务标识
  "data_type": "trace" // 数据类型，固定为trace
}

统一规范

标识规范：Trace ID采用UUIDv4 格式，Span ID采用8位十六进制格式，确保全局唯一；
调用关系：通过parent_span_id明确父节点，实现链路调用拓扑的自动生成；
耗时计算：统一为end_time - start_time，单位为毫秒（ms），保留0位小数；
状态规范：仅保留SUCCESS/ERROR两种状态，避免自定义状态（如FAILED/EXCEPTION）；
操作名：统一为接口名/方法名（如createOrder、/api/v1/order），避免无意义的操作名。

3. 统一标签体系规范

为所有数据打上企业级统一标签 ，实现按业务、集群、拓扑、环境 多维度的数据分析和筛选，标签分为基础标签、业务标签、环境标签三类，所有标签均采用**"键值对"** 格式，键名统一小写+下划线，值名统一小写+横线。

统一标签体系

标签类型	标签键	标签值示例	说明	必选
基础标签	instance_id	node-01、container-nginx-02	资产实例唯一标识	是
基础标签	cluster_id	cluster-prod-01、cluster-test-02	集群标识	是
基础标签	node_type	physical、virtual、container	节点类型	是
业务标签	business_id	e-commerce-trade、finance-pay	业务线标识	是
业务标签	service_name	order-service、pay-service	微服务名	是
业务标签	module_name	order-create、order-query	业务模块名	否
环境标签	env	prod、test、dev	部署环境	是
环境标签	region	cn-beijing、cn-shanghai	部署地域	是

六、工程落地要点与工具选型清单

1. 企业级落地核心要点

小步快跑，场景化落地 ：先从核心业务线（如交易/支付）开始，落地日志/指标/链路的采集、整合和标准化，验证效果后再推广至全公司，避免"大而全"的盲目建设；
工具统一，减少技术栈 ：基于OpenTelemetry/Prometheus/ELK主流生态选择工具，减少自定义开发和小众工具的使用，降低后续维护成本；
标准化先行，强制执行 ：制定企业级数据标准化手册 ，并通过技术手段（如采集Agent强制打标、治理层格式校验）确保标准的强制执行，避免人工干预导致的标准失效；
性能损耗管控 ：将采集/传输/治理的系统性能损耗控制在5%以内，链路采样率默认1%，日志采集过滤无用内容，指标采集增量拉取；
高可用保障 ：采集层、传输层、治理层均采用分布式部署，核心组件（如Kafka/Prometheus）主从备份，避免单点故障导致的采集中断；
监控与审计：对采集系统自身进行监控（如Agent存活状态、采集延迟、丢数率），同时对数据标准化执行情况进行审计，及时发现并整改非标准数据；
人员培训 ：对开发、运维、测试人员进行数据采集与标准化培训，确保开发人员在埋点/日志打印时遵循企业标准，运维人员掌握采集工具的配置和维护；
持续迭代：根据业务发展和AIOps分析需求，持续迭代数据标准和采集方案，预留扩展字段和标签，适配业务的个性化需求。

2. 企业级工具选型清单（云原生/传统架构通用）

架构层	核心功能	推荐工具	备选工具	适用场景
采集层	指标采集	Prometheus Exporter、Node Exporter、cadvisor	Zabbix Agent、Nagios	基础资源/中间件/容器指标
采集层	日志采集	Filebeat、Fluent Bit	Fluentd、Logstash	轻量级日志采集，低资源占用
采集层	链路采集	OpenTelemetry Agent/SDK	SkyWalking Agent、Pinpoint	无侵入/低侵入全链路采集
传输层	统一消息队列	Kafka	RabbitMQ、RocketMQ	高吞吐、高可靠数据传输
治理层	数据清洗/标准化	Logstash、Flink	Spark、Fluentd	实时数据清洗、打标、融合
存储层	指标存储	Prometheus、VictoriaMetrics	InfluxDB、TDengine	时序指标存储、实时查询
存储层	日志存储	Elasticsearch、ClickHouse	Splunk、ELK Stack	日志全文检索、统计分析
存储层	链路存储	Jaeger、Tempo	Elasticsearch、Zipkin	链路存储、拓扑分析、可视化
存储层	元数据/标签存储	MySQL、ETCD	MongoDB、Redis	标准配置、标签体系、元数据存储
可视化层	统一可视化	Grafana、Kibana	SkyWalking UI、Prometheus UI	指标/日志/链路统一查询、可视化

七、总结

日志/指标/链路数据的整合与标准化 是AIOps落地的基础和前提，没有高质量、可关联、标准化的运维数据，后续的特征工程和智能分析都将成为"空中楼阁"。其核心并非简单的工具堆砌，而是**"架构设计+采集方案+统一整合+标准化规范+工程落地"** 的系统性工程，核心目标是打破数据孤岛，实现"一次请求、全链路数据关联，一个故障、全维度数据分析"。

在实际落地中，需遵循**"采集解耦、统一传输、标准化治理、分级存储、全局关联"** 原则，基于OpenTelemetry/Prometheus/ELK主流生态打造统一的采集架构，同时制定企业级统一标准 并强制执行，小步快跑、场景化落地，将数据治理的成果转化为AIOps智能分析的核心能力，最终实现运维工作的智能化、自动化、可预测。

AIOps 数据采集：日志/指标/链路数据的整合与标准化

一、AIOps 三类核心数据的特征与采集痛点

1. 三类核心数据的核心特征对比

2. 企业级采集核心痛点

二、AIOps 数据采集整体架构设计

1. 四层采集架构核心设计

2. 架构核心设计原则

三、日志/指标/链路 分类型采集方案

1. 指标数据采集方案（时序化、结构化采集）

核心采集工具

核心部署方式

关键配置要点

2. 日志数据采集方案（全量、实时、低侵入采集）

核心采集工具

核心部署方式

关键配置要点

3. 链路数据采集方案（全链路、低侵入、关联采集）

核心采集工具

核心部署方式

关键配置要点

四、日志/指标/链路 数据统一整合方法

1. 核心整合维度：三大全局唯一标识

标识传递原则

2. 核心整合方法：四类关联融合

（1）全链路请求关联：Trace ID/Request ID 核心关联

（2）资产节点关联：Instance ID/Node ID 物理关联

（3）业务服务关联：Business ID/Service ID 业务关联

（4）时序对齐关联：时间戳 时序关联

3. 整合落地工具与流程

核心整合工具

核心整合流程

五、日志/指标/链路 数据标准化规范

1. 标准化核心框架："必选字段+扩展字段+标签体系"

2. 分类型标准化规范（企业级可直接落地）

（1）指标数据标准化规范（时序结构化）

必选字段

统一规范

（2）日志数据标准化规范（结构化）

必选字段（JSON格式）

统一规范

（3）链路数据标准化规范（全链路结构化）

必选字段（JSON格式）

统一规范

3. 统一标签体系规范

统一标签体系

六、工程落地要点与工具选型清单

1. 企业级落地核心要点

2. 企业级工具选型清单（云原生/传统架构通用）

七、总结

三、日志/指标/链路分类型采集方案

四、日志/指标/链路数据统一整合方法

（4）时序对齐关联：时间戳时序关联

五、日志/指标/链路数据标准化规范