3. 服务画像数据采集：日志、指标、调用链、配置管理数据库（CMDB）的数据整合
服务画像的构建依赖于多源数据的融合。单一数据源（如仅依赖指标）无法完整描述服务的运行时状态与依赖关系。本章节聚焦于如何将日志、指标、调用链与 CMDB 数据进行结构化整合，形成统一的画像数据底座，为后续异常检测与容量压测水位调整提供可靠输入。
3.1 四类数据源的角色与采集粒度
不同数据源在服务画像中承担不同角色，采集频率与存储周期差异显著。下表梳理了核心差异：
| 数据源 | 画像维度 | 典型采集粒度 | 存储周期 | 关键字段示例 |
|---|---|---|---|---|
| 日志 | 错误模式、请求详情、业务状态 | 单条请求 / 事件 | 7~30 天（热） | timestamp, level, traceId, message, exception |
| 指标 | 资源利用率、吞吐量、延迟分布 | 10s ~ 1min（聚合） | 30~90 天（降采样） | cpu_usage, qps, p99_latency, error_rate |
| 调用链 | 服务依赖拓扑、调用耗时、上下游关系 | 单次请求全链路 | 1~7 天（采样） | spanId, parentSpanId, serviceName, duration, status |
| CMDB | 部署拓扑、实例归属、配置基线 | 变更驱动 / 定时同步 | 长期（全量） | app_id, host_ip, cluster, owner, deploy_version |
实践建议：日志与调用链数据量巨大，建议在采集端即完成结构化解析（如日志转 JSON、调用链采样率控制），避免在画像聚合层产生性能瓶颈。
3.2 数据整合流程与关键步骤
数据整合并非简单的“汇聚”，而是需要经过采集、清洗、关联、归一化四个阶段。以下流程图展示了完整的整合链路：
3.3 核心关联逻辑：traceId 与 instanceId 双纽带
数据关联是整合的关键难点。实践中，我们依赖两个核心标识符完成跨源连接：
- traceId（链路追踪 ID）：贯穿日志与调用链。日志系统在输出时携带 traceId，调用链系统以 traceId 为根组织 span 树。通过 traceId 可将单次请求的日志事件与完整的调用拓扑对齐。
- instanceId（实例标识）：贯穿指标与 CMDB。指标采集时附加 instanceId（或 host_ip + port 组合），CMDB 中记录每个 instanceId 的部署信息（集群、版本、容器规格）。通过 instanceId 可将资源指标与配置基线绑定。
常见陷阱：日志中 traceId 字段缺失或格式不一致（如部分服务使用 UUID，部分使用雪花 ID）会导致关联失败。建议在日志采集端强制校验 traceId 格式，并在清洗阶段做统一转换。
3.4 归一化后的画像宽表结构
经过清洗、关联、归一化后，最终输出一张服务画像宽表，作为异常检测与容量分析的统一数据视图。典型字段结构如下：
| 字段分组 | 字段名 | 来源 | 说明 |
|---|---|---|---|
| 基础标识 | service_name | CMDB | 服务唯一名称 |
| instance_id | CMDB + 指标 | 实例唯一标识 | |
| cluster | CMDB | 所属集群 / 泳道 | |
| 运行时指标 | cpu_usage | 指标 | CPU 利用率（归一化至 0~100） |
| qps | 指标 | 每秒请求数 | |
| p99_latency_ms | 指标 | P99 延迟（毫秒） | |
| 调用拓扑 | upstream_services | 调用链 | 上游依赖服务列表 |
| downstream_services | 调用链 | 下游被调服务列表 | |
| 错误与异常 | error_rate | 指标 + 日志 | 错误率（融合计算） |
| top_exceptions | 日志 | Top N 异常类型及出现次数 |
3.5 数据整合的工程化保障
为保证画像数据的时效性与准确性，需在采集管道中嵌入以下机制：
- 采集端幂等性：日志与指标采集器需支持去重（如基于 offset 或 dedup key），避免重复数据污染画像。
- 时间窗口对齐：指标通常按固定窗口聚合（如 1min），日志与调用链需按同一窗口做降采样或对齐，否则关联时会出现时间偏差。
- CMDB 变更感知：CMDB 数据变化（如扩缩容、版本升级）应通过 webhook 或 CDC 机制实时通知采集管道，避免画像使用过期配置。
- 数据质量监控：对画像宽表中的关键字段（如 traceId 缺失率、instanceId 匹配率）设置告警阈值，低于阈值时触发数据修复流程。
容量压测前置检查：在启动压测水位调整前，务必验证画像数据整合的完整性。若 instanceId 匹配率低于 95% 或 traceId 关联率低于 80%，应先修复数据管道，否则异常检测结果将不可信。
3.6 整合后的数据流向
最终，归一化后的服务画像宽表将同时输入异常检测引擎与容量压测水位计算模块。下图展示了数据整合后的下游消费关系：