基于 OPLG 从 0 到 1 构建统一可观测平台实践

应用架构与可观测技术演进历程

在软件开发早期，单体应用架构因其结构简单，便于测试和部署，得到了广泛的应用，对应的监控诊断技术主要是基于日志和日志关键词的指标监控。随着软件复杂度的不断提升，单体应用架构逐步向分布式和微服务的架构演进，整体的调用环境也越来越复杂，仅靠日志和指标渐渐难以快速定位复杂环境下的问题。

因此，链路追踪技术应运而生。但早期的链路追踪技术和日志指标的结合比较简单，更多的是在应用层以 APM 软件的形式存在。

随着云计算和云原生理念的普及，从业务层到应用层，容器和基础设施之间的边界不断地被打破，研发、运维、安全等工种的职责也不断模糊，因此对于全栈可观测的诉求也变得愈加强烈，Traces、Metrics 和 Logs 的连接也愈发紧密。

一个典型的云原生架构及可观测诉求

典型的云原生架构往往是混合云的形态，出于安全或容灾等方面的考虑，可能会将一部分应用部署在公有云，另一部分部署在自建机房。而出于软件研发效率和性能的考虑，不同的应用又可能采用多种开发语言，因此可观测诉求可以被归纳为以下四点：

1、全栈立体化统一监控与告警：比如可以将业务层的交易量、支付量的业务指标和应用黄金 3 指标、基础设施的 CPU 利用率以及网络情况，放在一张大盘上做总体监控，这也是大促期间较为常用的方式。

2、前后端/多语言全链路追踪：用户请求从端上发起，一直到网关，再到后端的应用和云组件之间调用轨迹的追踪，可以快速定位用户请求在哪里有异常。

3、跨云数据统一可视化：将不同类型的数据、不同环境的数据进行统一可视化，需要有较强的可视化组件。

4、开源格式数据二次加工：出于业务自定义的需求，需要有二次加工与分析。如果能够基于开源的数据格式标准，很多工作实施起将会比较轻松，也可以复用很多现有的东西。

为什么要基于 OPLG 构建统一可观测平台

而传统的监控诊断平台往往存在以下几个痛点：

1、很多埋点插桩由用户自己实现，这种闭源实现会导致数据格式不统一，而且埋点在各个系统之间很难复用，接入成本非常高。

2、Metrics 指标孤立地分散在各个监控的子系统，比如有的在网络，有的在应用，有的在容器。排查全链路问题时，对开发使用人员的经验要求非常高，且效率非常低。

3、Traces 会由于埋点覆盖度不够或协议不统一而无法串联，导致经常出现断连。

4、日志或链路数据的明细数据全量上报到服务端，也会带非常高的成本，而且查询率较低，还会引发热点的性能瓶颈。

5、自建控制台的前端开发成本高，开发周期长，灵活性较差，很难跟上业务迭代的效率。

6、各个系统的可观测数据之间缺乏统一的标签管理，关联性较差，很难做综合性的分析。

为了解决上述问题，我们在生产环境中逐渐沉淀下较为可行的方案，即基于 OPLG 建设统一可观测平台。此方案主要有以下几点优势：

1、开源开放：全开源技术栈，借助社区共建合力，比如可以借助 OpenTelemetry 的 Traces 埋点，Prometheus指标的 Metrics Exporters ，无需过多开发，即可保障大部分通用组件数据的采集生成上报，降低了接入成本。

2、统一目标：开源且基于统一的一套规范，可以很轻松地实现内部各个子系统甚至是和外部三方系统之间的打通和关联分析。

3、自由灵活：基于 OPLG 特别是 Grafana 一些比较好的设计，可以非常灵活地组织可观测数据，能够灵活地定制每一个场景下需要的大盘图表，满足自定义的需求。

4、边缘计算：基于 OpeTelemetry Collector技术，可以将数据处理“左移”到用户集群内。通过边缘计算的技术，能够提前提炼数据价值，并将提炼好的数据再发送到服务端，降低公网传输的成本以及服务端的存储成本。

基于 OPLG 构建云原生可观测平台方案