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

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

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

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

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

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

全栈立体化统一监控与告警：比如可以将业务层的交易量、支付量的业务指标和应用黄金三指标、基础设施的 CPU 利用率以及网络情况，放在一张大盘上做总体监控，这也是大促期间较为常用的方式。
前后端/多语言全链路追踪：用户请求从端上发起，一直到网关，再到后端的应用和云组件之间调用轨迹的追踪，可以快速定位用户请求在哪里有异常。
跨云数据统一可视化：将不同类型的数据、不同环境的数据进行统一可视化，需要有较强的可视化组件。
开源格式数据二次加工：出于业务自定义的需求，需要有二次加工与分析。如果能够基于开源的数据格式标准，很多工作实施起将会比较轻松，也可以复用很多现有的东西。

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

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

很多埋点插桩由用户自己实现，这种闭源实现会导致数据格式不统一，而且埋点在各个系统之间很难复用，接入成本非常高。
Metrics 指标孤立地分散在各个监控的子系统，比如有的在网络，有的在应用，有的在容器。排查全链路问题时，对开发使用人员的经验要求非常高，且效率非常低。
Traces 会由于埋点覆盖度不够或协议不统一而无法串联，导致经常出现断连。
日志或链路数据的明细数据全量上报到服务端，也会带非常高的成本，而且查询率较低，还会引发热点的性能瓶颈。
自建控制台的前端开发成本高，开发周期长，灵活性较差，很难跟上业务迭代的效率。
各个系统的可观测数据之间缺乏统一的标签管理，关联性较差，很难做综合性的分析。

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

开源开放：全开源技术栈，借助社区共建合力，比如可以借助 OpenTelemetry 的 Traces 埋点，Prometheus 指标的 Metrics Exporters ，无需过多开发，即可保障大部分通用组件数据的采集生成上报，降低了接入成本。
统一标准：开源且基于统一的一套规范，可以很轻松地实现内部各个子系统甚至是和外部三方系统之间的打通和关联分析。
自由灵活：基于 OPLG 特别是 Grafana 一些比较好的设计，可以非常灵活地组织可观测数据，能够灵活地定制每一个场景下需要的大盘图表，满足自定义的需求。
边缘计算：基于 OpenTelemetry Collector技术，可以将数据处理“左移”到用户集群内。通过边缘计算的技术，能够提前提炼数据价值，并将提炼好的数据再发送到服务端，降低公网传输的成本以及服务端的存储成本。

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

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

端侧数据生成与上报：通过 OpenTelemetry 完成 Traces 数据的生成，通过 Prometheus 完成指标类的数据，通过 Loki 的方式完成日志采集。
边缘侧数据统一处理与路由：所有数据采集完成之后，可以通过 OpenTelemetry Collector 完成数据统一的边缘处理和路由转发。
全托管服务端：能够提供更好的性能和更稳定的服务，而且不会绑定技术栈，迁移的自由度和灵活度高。
统一可视化：可以通过 Grafana 完成统一的自定义灵活监控，也可以采用云服务商比如 ARMS 在特定的精细化交互场景提供精细化的交互大盘，提高查询体验。此外，如若有自己的需求，也可以通过开源的数据格式或开放的 OpenAPI 建设自己的控制台。

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

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

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

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

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

基于 ARMS 的托管服务端针对海量的数据场景做了很多查询性能优化加速的技术：

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

除了海量数据的查询性能优化外，我们在 HA 侧也做了体系化的建设：

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

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

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

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

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

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

Demo演示1：如何基于 OpenTemeletry和 ARMS 实现全链路的追踪和应用诊断

进入ARMS 控制台-接入中心，找到 OpenTelemetry 的接入方式（也可以选择其他的接入方式）。以 Java 应用为例，可以通过 OT Java Agent 生成数据，然后修改启动参数，比如接入点或鉴权的 Token 。

除了直接上报，也可以通过 OT Collector 完成数据转发，实现无损统计，只需要将 Endpoint 改成本地服务。

安装完成后，即可通过 ARMS 提供的 Trace Explorer 页面进行调用链的分析。

调用链的分析是强交互场景，比如可以通过左侧的快捷筛选快速过滤出异常调用链路，然后选择其中一条链路查看端到端的全链路轨迹。

ARMS 在 Java 场景针对接口粒度做了更详细的本地方法埋点，能够更好地定位根因。上图右侧可以看到当前 Span 相关的附加信息，包括 JVM 和主机的监控指标。

与 Span 相关的应用日志也能很快速地集成，排查业务问题可以结合日志更好地定位。

Trace Explorer 除了调用链的查询外，也可以做实时的动态分析。比如可以查看异常链路是否集中在某特定IP ，是否存在单机故障的可能性，或是否集中在特定的接口。也可以将很多调用链进行全链路的聚合，多条链路可以看到每一个分支的情况，也可以看到应用维度更直观的拓扑。

此外，ARMS 还针对 Java 提供了较好的交互图表。除了JVM 监控、主机监控外，还包括容器的 Pod 监控、线程池监控等。业务高峰期很容易出现数据库连接池打满等情况，以往此类问题难以排查。但有了池化监控，即可一眼定位到问题所在。通过上下游的分析，能够很轻松地获知当前应用调用方的情况。

在数据库调用里可以看到 SQL 的明细统计以及缓存的操作情况。

ARMS 还提供了高阶的诊断能力，比如线程分析，可以针对每一类线程池观察线程消耗的 CPU 、耗时以及线程数，也可以查看方法栈。

针对 Java 应用的疑难问题，可以通过白屏化的 Arthas 诊断实时抓取捕获 JVM 运行态的数据，比如查看方法调用的轨迹、参数。

除此之外，还可将 APM 的指标数据写到 Prometheus，通过 Grafana 做展示。用户可以通过 PromQL 定制自己想要的 APM 大盘，可以将 APM 数据和其他指标数据比如业务、基础设施、云组件、数据库服务端、容器等放在一起，定制自己的大盘形态。

Demo演示2：如何基于 Prometheus和 Grafana 做统一的监控和告警

首先，在接入中心选择要接入的组件，有 MySQL 、Redis 、ES 等，默认支持阿里云上的很多组件。

以 MySQL 为例，首先选择要接入的实例，填写 Exporter 名称，选择地址，再写入用户密码，此处也可以查看当前 Exporter 采集的指标。

如果实例未接入，可以选择新建实例。比如针对 ECS 环境或自建机房，可以通过下载 ARMS 提供的 Helm 安装 Prometheus Agent ，也可以通过 Remote Write 的方式直接上报数据。如果希望将多个地域的数据源放在一起查看，也可以通过 Global View 全局接口实例将多个数据进行统一展示。