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

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

因此，链路追踪技术应运而生。但早期的链路追踪技术和日志指标的结合比较简单，更多的是在应用层以 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 构建云原生可观测平台方案

OPLG 主要由以下四个模块构成：

1、端侧数据生成与上报：通过 OpenTelemetry 完成 Traces 数据的生成，通过 Prometheus 完成指标类的数据，通过 Loki 的方式完成日志采用。

2、边缘侧数据统一处理与路由：所有数据采集完成之后，可以通过 OpenTelemetry Collector 完成数据统一的边缘处理和路由转发。

3、全托管服务端：能够提供更好的性能和更稳定的服务，而且不会绑定技术栈，迁移的自由度和灵活度高。

4、统一可视化：可以通过 Grafana 完成统一的自定义灵活监控，也可以采用云服务商比如 ARMS 在特定的精细化交互场景提供精细化的交互大盘，提高查询体验。此外，如若有自己的需求，也可以通过开源的数据格式或开放的 OpenAPI 建设自己的控制台。

基于 OpenTelemetry Collector 实现统一数据采集与边缘计算

OpenTelemetry Collector 首先会完成统一的数据采集，任何数据类型都可以进行数据采集，然后做通用的处理，比如格式化、数据的标签打标，还可以进行一些指标的预聚合动作，最常见的比如调用链，可以根据 service IP 等粒度先将数据聚合再进行采样，可以保证指标的精准度，而且上传到服务端也可以降低成本。

OpenTelemetry Collector 还可提供本地存储的能力，可以将一部分最近的数据先临时缓存，然后进行比如最近 10 分钟的全量查询、错慢全采等，可以更好地利用边缘的存储能力。

针对处理好的数据， OpenTelemetry Collector 提供了非常灵活的转发方式，可以支持不同的协议，比如 Prometheus 协议、OTLP 协议等，也可以支持多数据源的转发，可以发送到云服务端，也可以转存到边缘存储，更加灵活。

基于 ARMS 托管服务端提供快速、稳定的查询体验

基于 ARMS 的托管服务端针对海量的数据场景做了很多查询性能优化加速的技术，比如通过算子下推的方式，在 70% 以上的场景下查询性能相对于开源提升了 10 倍以上；而针对 7-10 天等的长周期查询，通过降采样技术又进一步地提升了一个数量级的查询性能；针对 URL 等发散维度，通过自动收敛的技术很好地解决了热点导致的查询卡顿问题；针对链路数据，做了对应用和 Traces ID 两级的路由扫描，针对链路查询的使用特征做了相应的优化。

除了海量数据的查询性能优化外，我们在 HA 侧也做了体系化的建设，比如默认支持全球部署、多可用区的容灾，避免了单个 region 或 AZ 不可用的风险；其次业务经常会遇到突发的流量或用户快速增长，如果是自建机房则需要考虑容量问题，而使用 ARMS 可以根据流量自适应地做扩充，无需担心突发流量带来的性能瓶颈；极端情况下，也可以通过动态配置下推或自动流控降级保障核心功能的可用性；最后，提供了全链路 SLA 监控和预警的建设，有 7*24 小时的应急响应，可及时发现可用性问题并快速恢复。

基于 Grafana+ARMS 构建灵活、精细的可视化界面

此外，基于 Grafana +ARMS 提供了灵活、精细的可视化体验。

Grafana 丰富的仪表盘插件和广泛的数据源支持，可以将各种数据都集成在一个大盘里。而且通过 PromQL、LogQL 等灵活的查询语法，不需要前端介入。后端的研发，测试，SRE 等可以通过低代码的形式快速构建自己的场景大盘，提升可观测的效率。

得益于 Grafana 的开源属性，如果想从自建机房迁移到云上，或在云之间互相迁移，整个可视化平台都能够通过 JSON 文件或其他方式快速拷贝，轻松完成端到端的迁移，不会被特定的厂商强绑定。

但是 Grafana 也存在缺陷，比如它在交互场景的体验不够好，因此 ARMS 在调用链的关联分析、在线诊断、配置管理等强交互的场景提供了更精细化的交互页面。ARMS 还会进一步增强 Grafana 的图表插件，提供新的图表插件以提升托管版 Grafana 的可视化能力。