核心要点
- 统一观测平台建设的第一道难题，通常不是新系统怎么选，而是现有观测系统的数据如何处理。
- 完全重建适合从零开始的企业，但对存量系统多的企业成本和风险都很高。
- 数据集成有两类实现：转储转换和 API 对接。前者统一数据标准，后者尽量保留现有系统和数据标准。
- Flashcat 面向存量观测系统较多的企业，主要推荐 API 对接式数据集成，降低接入、运行和学习成本。
- 数据源集成能力会影响上层告警、仪表盘、查询、灭火图和 AI 分析能否统一工作。
观测系统过于分散是一个由来已久的问题。一次故障处理可能涉及查询指标系统、日志系统、链路系统。这些观测系统还可能因环境不同而不同：容器环境使用 Prometheus + Grafana，物理机或虚拟机环境使用 Zabbix，私有云环境使用夜莺、Elasticsearch、SkyWalking，公有云环境则使用各家云厂商的指标、日志、链路系统。
据统计，当前 80% 的 IT 企业同时存在 10 个及以上的观测系统。可能只有少数工程师，甚至没有一个工程师同时拥有全部这些观测系统的权限，更别提用好这些系统。
分散的观测系统学习和使用成本高，体验差，严重影响服务故障处理速度。因此，大部分企业都在寻求统一观测方案。特别是在 OpenTelemetry 标准出现后，统一观测已经成为大势所趋。
那么，当前统一观测系统建设的难点是什么？
第一个难点：存量观测系统如何处理
统一观测系统的建设有很多难点。本文主要讨论起步就会遇到的第一个难点：如何从现有观测系统过渡到新的观测系统，现有观测系统的数据如何处理？
当前解法主要有两种：
| 方案 | 做法 | 适用情况 |
|---|---|---|
| 完全重建 | 重新建设或引入新的统一观测系统，重新采集数据，替代当前分散系统 | 从零开始建设观测系统的企业 |
| 数据集成 | 把现有观测系统的数据统一集成到新平台，利旧现有数据 | 存量观测系统较多的企业 |
完全重建的风险主要有两点：
- 所有数据可能要重新采集，这是巨大投入，尤其是日志、链路这类采集较重的数据。
- 新观测系统最终不一定能得到用户认可，但前面的采集成本已经投入，导致进退两难。
这种方案风险和成本较大，对存量观测系统较多的企业需慎重采用；对于从零开始建设观测系统的企业，因为没有存量负担，可以考虑。
数据集成的两种实现方式
这里重点讨论数据集成。数据集成又存在两种不同实现：
| 实现方式 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| 转储转换 | 将现有观测系统的数据转储到统一观测系统，并转换为新系统的数据标准 | 上层功能使用统一数据标准，查询、告警、仪表盘配置更一致 | 数据重复存储，用户可能要同时掌握新旧两种数据标准 |
| API 对接 | 对接现有观测系统 API，不做数据转储和转换，只在上层功能需要时查询 | 不重复存储数据，不改变原有数据标准，降低用户迁移成本 | 上层功能需要针对不同数据源适配，平台供应商开发成本更高 |
如果区分观测系统的用户和供应商来看，方案 B “API 对接”的好处更多留给用户，开发成本在供应商；方案 A “转储转换”则相反。
Flashcat 的数据集成方案
Flashcat 是一个从数据到平台到场景的一体化可观测性产品，基于开源夜莺实现，具备完整的指标、日志、链路数据采集能力和完备的可观测系统功能。
针对存量观测系统较多的企业，Flashcat 的统一观测系统建设方案，主要推荐采用数据集成，并对存量观测系统进行 API 对接，尽可能降低企业接入、运行和学习成本。
Flashcat 在服务客户的过程中不断积累集成的观测系统数据源，目前已集成数十种开源和公有云观测系统，基本覆盖市面上常见的开源和公有云观测系统。不断积累的观测系统数据源集成能力，已成为 Flashcat 的核心能力之一，并得到用户的广泛认同。
为什么 API 对接更适合很多存量企业
API 对接不是技术上最省事的方案，但对用户更友好，原因在于：
- 不强制迁移数据：存量系统继续保留，减少一次性替换风险。
- 不重复存储数据：避免日志、链路等大体量数据重复转储。
- 不改变已有数据标准：用户不需要立刻学习一套新指标、标签和查询标准。
- 上层能力仍可统一：告警、仪表盘、数据查询、灭火图、巡检和 AI 分析可以通过数据源名称引用不同系统。
对企业来说，统一观测建设的目标不是为了“消灭所有旧系统”，而是先让故障处理、告警、可视化和分析入口统一起来。API 对接式数据集成更符合这个现实路径。
选型判断
企业可以用以下问题判断更适合哪条路径：
| 问题 | 倾向完全重建 | 倾向 API 对接式集成 |
|---|---|---|
| 是否已有大量存量观测系统 | 否 | 是 |
| 日志、链路等重数据是否已经稳定采集 | 否 | 是 |
| 是否能接受一次性迁移和重采集成本 | 是 | 否 |
| 是否希望尽量保留原数据标准 | 否 | 是 |
| 是否优先解决统一入口和故障处理效率 | 不一定 | 是 |
总结
统一观测平台建设中，存量系统处理方式会决定后续成本和风险。
完全重建适合没有历史负担的企业；转储转换适合强统一数据标准的场景；API 对接式数据集成更适合存量系统多、数据采集成本高、希望平滑过渡的企业。
Flashcat 选择的路径，是通过数据源集成把现有观测系统接入统一平台，让上层告警、仪表盘、查询、灭火图和 AI 分析能够共享这些数据通道。
如果你的统一观测系统建设思路也和我们一致，欢迎交流！
FAQ
Q1：数据集成是不是意味着所有数据都要复制到 Flashcat？
A：不是。文章中的 Flashcat 数据集成方案强调 API 对接，不做数据转储和转换，而是在上层功能需要时按需查询。
Q2：转储转换和 API 对接哪个更好？
A：没有绝对答案。转储转换利于统一数据标准，但会带来重复存储和迁移成本；API 对接更利于利旧存量系统，但要求平台侧适配更多数据源。
Q3：数据源集成后，上层功能如何使用这些数据？
A：观测系统在 Flashcat 集成后会生成可自定义名称。上层产品可以通过引用这个数据源名称，完成告警配置、仪表盘配置、数据查询、权限管理等操作。
