结论先行：建设一体化可观测平台，不需要把已有监控全部推倒重来。可行做法是把数据分成指标、链路、日志与业务事件四类，沿用既有采集器，通过标准协议或日志文件系统性地汇入统一平台。真正需要新建采集的通常只有应用侧链路，主机、网络与中间件指标可以复用现有投入。接入时要盯住三件事：单位与口径统一、实体关系补齐、时钟同步。
为什么不建议一次性替换
"上一套新平台、下掉所有老工具"听起来干净，落地时却经常卡住，原因有三。
- 历史数据断裂。容量趋势、同比环比、故障对照都依赖历史曲线，切换意味着重新积累。
- 告警规则要重写。既有阈值和升级流程是多年调优的结果，一次性推倒会引入新的漏报与误报。
- 采集盲区风险。新采集器在小众设备、老旧系统上未必立刻适配，覆盖度不升反降。
更稳妥的路径是"先接入、后收敛"：让新平台成为统一的分析入口，采集侧逐步归一。
四类数据源的接入方式
| 数据类型 | 常见来源 | 接入方式 | 接入注意点 |
|---|---|---|---|
| 指标 | 主机与容器资源、中间件、网络设备 | 标准协议抓取或推送；无接口时解析日志文件 | 统一单位与采集间隔，补齐服务、实例、主机三层归属 |
| 链路 | 应用侧探针、开放标准协议上报 | 探针无侵入注入或按开放协议接入 | 链路标识在入口生成并全程透传，异步环节别断链 |
| 日志与事件 | 系统日志、消息队列、应用日志文件 | 日志接收端接入或消息队列订阅 | 日志中注入链路标识，才能与调用链互相下钻 |
| 业务事件 | 交易结果、转化节点、批次作业状态 | 业务侧按约定字段埋点上报 | 先定义三到五个黄金指标，不要一上来全量埋点 |
三个最容易踩的坑
单位与口径不统一
毫秒与微秒、字节与位、每秒请求数与每分钟请求数，混在一起会让趋势图完全失真。接进来之前先定一张单位对照表，在接入层做强制转换，而不是留给看图的人自己去换算。
实体关系缺失
很多指标只带着主机名或 IP，没有服务名和实例标识，结果是能画曲线、却没法与调用拓扑关联，故障依旧要跨系统核对。接入时应补齐"服务—实例—主机—容器"的归属关系。
时钟不同步
跨源数据对不上时间戳，是关联分析最常见的失败原因。各采集点统一走内部时间源，并在接入校验时把时间偏差纳入检查项。
接入顺序建议
| 阶段 | 接入范围 | 验收标准 |
|---|---|---|
| 第一阶段 | 核心交易链路的应用指标与调用链 | 能在同一界面从接口下钻到语句与外部调用 |
| 第二阶段 | 主机、容器、中间件指标 | 指标可关联到服务拓扑，不再是孤立曲线 |
| 第三阶段 | 日志与业务事件 | 报错日志可一键跳转到对应调用链 |
| 第四阶段 | 既有监控工具的历史数据与告警 | 告警统一收敛，历史曲线可对照查询 |
怎么验证接进来的数据可用
接入完成不等于可用。建议用三个问题做验收：能否按服务名查出它依赖的所有实例；能否从一条报错日志跳到对应调用链；能否按业务字段检索到单笔交易的完整路径。三个问题都能答上来，数据才算真正打通。
先把分析入口统一
与其纠结"先换哪个采集器"，不如先把分析入口统一。数据都在一个界面里关联，采集侧的替换就变成了可以按节奏推进的工程，而不是一次高风险的整体切换。
奇摩在实施这类项目时，通常建议先选一到两条核心交易链路做试点，验证接入完整性后再分批铺开，避免一次性接入带来的排查成本。若您需要评估现有监控资产的接入路径，欢迎预约咨询。