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

Posted 2022-08-05 阿里云云栖号

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

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

因此，链路追踪技术应运而生。但早期的链路追踪技术和日志指标的结合比较简单，更多的是在应用层以 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 的可视化能力。

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

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

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

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

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

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

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

Traces 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 全局接口实例将多个数据进行统一展示。

进入集成中心后，可以看到当前实例已经安装的组件，可以查看组件采集的指标，可以更精细化地选择哪些指标需要采集，哪些不需要。

大盘列表里，ARMS 提供了非常多预置的 Grafana 大盘，比如 K8s 的总览视图或 node 详情视图，可以查看当前节点各种状态，用户也可以基于视图自己编辑新的图表。

因为数据都写到 Prometheus，所以告警也可以基于 PromQL 扩展。我们提供了很多默认的告警模板，比如节点的 CPU 使用率等。除了可以定制告警内容，还可以选择通知策略，比如不同的告警发给不同的值班人员。

Grafana ARMS 提供了两种类型的 Grafana，分别是共享版本和托管的独占版本。我们更推荐开通独占的托管版本，可以做自定义的账号管理，也可以得到更好的可用性和安全性保障。

Demo 演示 3：基于 Loki 的日志查询分析

由于 ARMS 目前还没有提供商业化的 Loki 服务，因此本文将以官网的 Grafana 示例演示 Loki 的接入效果。

完成日志接入之后，可以基于 Loki 提供的 LokiQL 快速过滤。它还针对关键的索引字段建立了索引，基于这些字段可以进一步提升检索速度。

基于 Loki 可以定制形态较为丰富的图表。上图为官网提供的 Loki nginx 大盘，统计的数值或地域的分布等都可以通过 LogQL 定制，非常灵活。

Demo 演示 4：基于 RASP 的应用安全防护

• 危险组件检测

应用接入 RUSP 之后，可以自动根据 cve 标准扫描出当前应用是否存在危险组件，能够快速提示应用当前可能存在的风险。

可以查看实例详情和漏洞详情，包括具体的漏洞描述以及相应的修复方案，根据这个修复方案，即可完成漏洞修复。

除了已知的危险组件，也可以基于还未上报或特有的组件做全量组件自查。

• 应用安全的攻击防护

遭到恶意攻击后，系统能够自动识别出当前存在的恶意攻击行为，且可以看到攻击发生在哪个节点以及请求的参数和调用攻击的堆栈情况。

除了攻击识别外，还可以做主动防护，将防护模式从监控设置为监控并阻断。

修改防护模式后，针对最新的攻击行为，平台不只进行监控，还能够将它直接阻断，不影响业务的具体逻辑。同时抛出异常，提示当前风险行为已经被阻断。

Demo 演示 5：ARMS 提供的用户体验监控

在接入中心，可以针对不同类型的端侧设备进行监控。以 web 端为例，可以新建站点，选择相应的配置，然后通过 CDN 或 NPM 包的方式完成接入。

接入完成后，可查看当前控制台 PV、UV 以及 API 的请求成功率，并且可以看到请求分布在哪些地理位置、运营商或浏览器。

比如新开发了功能页面，可以查看页面 top 20 用户访问的情况，也可以选择具体的用户，通过会话追踪查看用户如何使用此产品，能够更好地观测用户行为。

应用前端监控还可以与拨测结合使用，可以通过拨测模拟真实的用户行为，对网站质量、网页性能、文件下载或 API 的性能做模拟，提前发现问题，先于用户感知到可能存在的风险。发现可用性出现异常后，可以针对不同的站点自动发送通知。

上图为已创建的 demo 任务，可以观测到网站的时延、丢包率以及每一次拨测的状态和结果，并且通过多维的报告查看问题聚焦在哪些地区等。

虽然 OPLG 并不能覆盖所有可观测领域，但它为可观测提供了非常良好的底座和规范。在这套体系的基础之上，可以不断地将其他可观测技术或产品能力集成进来，满足各种场景的可观测诉求，从而应对愈加复杂多变的环境带来的挑战。

云原生时代可观测技术的趋势与技术选型

云原生时代的可观测技术，在软件架构层面会更多地向分布式云和混合云的方向发展。同时容器化、微服务、 DevOps 甚至 DevSecOps 也将逐渐成为主流。

可观测技术趋势包括以下几个方面：

1、标准逐渐成型收敛。技术栈会向 OpenTelemetry、Prometheus 等方向收敛。而基于更加标准的数据，自动化的成本将会更低，效率将会更高。分层之间的监控边界被打破之后，监控立体化也将愈发成熟。

2、基于 eBPF 的网络和内核的无侵入探测，带来更多观测技术的可能性。

3、去中心化趋势。首先，数据去中心化，比如基于 OpenTelemetry Collector 可以将很多可观测的预处理左移到用户集群内，降低中心化服务端的压力。其次，协同去中心化，不仅可以在统一的控制台查看可观测数据，也可以在即时通讯软件比如钉钉完成整个协作的过程。

原文链接

本文为阿里云原创内容，未经允许不得转载。