结论先行：上一套新的可观测平台，不等于把旧的监控工具全部换掉。多数企业的现实是并存：主机监控跑了好几年，日志有自己的平台，前端另有拨测。新平台要做的是把数据接进来、把口径对齐，而不是重采一遍。想清楚三件事——哪些接、怎么接、什么时候下线——比"要不要换"更有用。
先盘一遍现有的，按四类看
盘点不是为了做资产台账，而是为了判断哪一类可以接、哪一类必须重来。
| 类别 | 典型现状 | 接入优先级 |
|---|---|---|
| 主机与系统指标 | 跑了几年的主机监控，覆盖 CPU、内存、磁盘、进程 | 高——数据已在，重采成本高、收益低 |
| 日志 | 独立的日志平台或检索系统，已按业务分好类 | 高——重复采集会带来两份口径 |
| 前端与拨测 | 页面性能、可用性拨测，多为独立工具 | 中——采集点位在新平台侧更容易补齐 |
| 调用链 | 部分系统有，多数没有或只在个别系统上开过 | 低——这一类通常要新建，旧数据参考价值有限 |
四类里，前两类的关键词是"别重采"，后两类的关键词是"能补就补"。判断依据很简单：旧工具采到的数据，是不是新平台自己也能采到，而且采得更细。如果答案是否，把它接进来。
三种接法，代价和留存的证据不一样
接法不是技术偏好问题，它决定了以后能不能拿这份数据去举证。
| 接法 | 怎么做 | 留下什么 | 丢掉什么 |
|---|---|---|---|
| 原生对接 | 用双方都支持的开放协议直连，指标与链路按标准格式入库 | 原始粒度、时间序列、可直接关联 | 旧系统里私有维度的部分字段 |
| 定期拉取 | 按固定间隔从旧系统的接口抓指标 | 聚合后的数值 | 间隔之间的波动，秒级排查时看不出来 |
| 日志与事件转发 | 把告警与操作事件以消息形式送到新平台 | 事件发生的时间与对象 | 原始明细，只能看到"发生过" |
定期拉取看着省事，问题在粒度。指标是每五分钟一个点，事后要回答"两点之间的那一分钟发生了什么"，数据里没有。这类数据适合看趋势，不适合做取证。
原生对接要提前确认两件事：旧工具那边有没有开这个接口、有没有许可限制。有些工具默认关闭，有些按接入对象数计费。这两件不确认，方案画得再好也落不了地。
同一台机器，在两套系统里得是同一个名字
接入做完之后最常见的故障不是数据不通，而是数据对不上：一个告警在新平台叫某个主机名，在旧系统叫一串 IP，报表上就变成了两台设备。
对齐要落在三个字段上。主机标识——用主机名还是资产编号，两套系统必须一致，且这个标识在 IP 变更时不变。业务归属——同一台机器挂在哪个业务系统下，两边用同一套标签。责任人——告警发给谁，两边指向同一个人。
三个字段里，主机标识最容易被忽略。虚拟机重建、IP 重分配、系统重装之后，用 IP 当主键的系统会出现"一台机器变成三台"的记录。可行的做法是以资产台账的编号作主键，IP 只作为属性，变更时改属性不改身份。
对齐这件事没有一次性做完的可能。新业务上线、系统迁移都会带来新的不对齐，所以要有一条定期比对的机制：按月抽一批主机的两套记录，看名称、归属、责任人是否一致，不一致的列出来改。这件事技术上不复杂，难在有人负责。
什么情况下旧工具确实该下线
并存不是长久状态，维护两套总要有理由。以下三种情况下线是划算的：授权到期且功能已被完全覆盖；两套采集造成同一指标两个数值，对外汇报时只能挑一套；旧工具的维护成本已经高于它带来的信息。
下线之前有个动作不能省：确认新平台上的历史数据能追溯到旧工具覆盖的时间段。很多单位在切换时才发现旧数据没有迁移，历史上那段时间成了空白，遇到需要追溯旧事的场景就断了。要留多长，取决于所在行业的留存要求，这个数应该由合规口径定，而不是由存储预算定。
边界与前提
本文只谈新平台与已建监控工具之间的数据怎么接、口径怎么对齐、旧工具什么时候可以下线，不谈该买一套还是几套，也不涉及采购价与预算比较。文中提到的接入方式与比对频次属一般性做法，具体以本项目现网工具清单与实测结果为准。
这类接入工作真正的难点在前期盘点和后期的口径维护，不在接口本身。深圳市奇摩计算机有限公司在做可观测项目交付时，会先把客户现有的监控工具与日志平台列成清单，标注哪些接、哪些重采、哪些下线，再动手部署。手上的工具清单如果还没理清，可预约咨询，从盘点开始。