关于阿里云:基于-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 构建云原生可观测平台计划

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 能够将很多可观测的预处理左移到用户集群内，升高中心化服务端的压力。其次，协同去中心化，不仅能够在对立的控制台查看可观测数据，也能够在即时通讯软件比方钉钉实现整个合作的过程。