统一观测系统建设中存量系统如何处理？

观测系统过于分散是一个由来已久的问题。一次故障处理可能涉及查询指标系统、日志系统、链路系统。这些观测系统很可能还因环境的不同而不同，如容器环境使用prometheus+grafana，物理机/虚拟机环境则使用zabbix，私有云环境使用开源观测系统，如夜莺、Elasticsearch、Skywalking，公有云环境则使用各家云厂商的指标/日志/链路系统。

据统计，当前80%的IT企业同时存在10个及以上的观测系统。可能只有少数工程师，甚至没有一个工程师同时拥有全部这些观测系统的权限，就更别提用好这些系统了。

分散的观测系统学习使用成本高，体验差，严重影响服务故障的处理速度。因此大部分的企业都在寻求统一观测的方案，特别是在Opentelementry标准出现后，统一观测已经成为大势所趋。

那么当前统一观测系统的建设有什么难点呢？

统一观测系统建设的难点和方案

统一观测系统的建设有很多难点，本文主要讨论起步就会遇到的第一个难点：如何从现有观测系统过渡到新的观测系统，现有观测系统的数据如何处理？

当前的解法主要有两种：

1. 完全重建：重新建设或引入一个新的统一观测系统，重新采集数据，完全替代当前分散的各个观测系统。2
2. 数据集成：把现有观测系统的数据统一集成到新的观测平台，利旧现有的数据。

方案1完全重建的风险有几点：

• 所有数据可能要重新采集，这是一个巨大的投入成本，特别是日志、链路这类采集较重的数据。
• 新的观测系统最终不一定能够得到用户的认可，但前面的采集成本已经投入，导致进退两难。

这种方案的风险和成本太大，对于存量观测系统较多的企业需慎重采用，从零开始建设观测系统的企业没有存量的负担，则可以考虑。

这里重点讨论方案2数据集成，在数据集成上又存在两种不同的实现：

• A. 转储转换：将现有观测系统的数据转储到统一观测系统，并转换为统一观测系统的数据标准。
• B. API对接：对接现有观测系统的API，不做数据的转储和转换，只在上层功能需要时进行查询。

方案A的好处是数据转储转换后，可以直接在上层的功能中使用，如查询数据、配置告警、配置仪表盘等，都是基于新系统的数据标准进行。缺点是数据实际上重复存储了，用户可能还要同时掌握新旧两种数据标准。

方案B则相反，好处是数据没有重复存储，数据标准也没有变化。缺点是上层的功能需要针对每类数据源都进行适配。如告警配置时需要指定集成的数据源，系统需具备从这类数据源查询数据进行计算和检测异常的能力。因此统一观测系统本身的开发成本会高于方案a。

如果区分观测系统的用户和供应商来看，方案B “API对接”的好处是留给用户的，而开发成本是在供应商。方案A “转储转换”则相反。

Flashcat 的数据集成方案

Flashcat 是一个从数据到平台到场景的一体化可观测性产品，基于开源夜莺实现。具备完全的指标、日志、链路数据采集能力和完备的可观测系统功能。

针对存量观测系统较多的企业，Flashcat 的统一观测系统建设方案，主要推荐采用数据集成，并对存量观测系统进行API对接的方案，尽可能降低企业的接入、运行和学习成本。

Flashcat 在服务客户的过程中不断积累集成的观测系统数据源，目前已集成了数十种开源和公有云的观测系统，基本覆盖了市面上常见的开源和公有云观测系统。不断积累的观测系统数据源集成能力已成为Flashcat的核心能力之一，得到了用户的广泛认同。

如果你的统一观测系统建设思路也和我们一致，欢迎交流！