ALL in one：如何搭建端到端可观测体系|学习笔记-阿里云开发者社区

开发者学堂课程【All In one：如何搭建端到端可观测体系：ALL in one：如何搭建端到端可观测体系】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/937/detail/14712

ALL in one：如何搭建端到端可观测体系

内容简介：

一、可观测的介绍

二、建设可观测体系关键要点

三、云原生可观测性覆盖数据

四、ARMS3.0云原生可观测平台

五、云上 ARMS 产品演示

六、Grafana + Prometheus 构建开源统一的可观测体系

七、演示

一、可观测的介绍

1、监控-APM-可观测，云原生时代的基础设施

很早之前可观测这一类产品或工具都叫做监控。为什么会有监控这样的一个产品呢？是因为跟整个应用的技术变革密切相关。在90年代开始形成的像客户端、 Servlet 端、CS 这种典型的两层应用，为了去监控这两层，确保在总结此类型应用的一个可用性，就产生了第一代的监控的软件。这个时期，最专注的点在于网络的性能，主机的性能，因为应用价格非常简单。

等到了2000年初 web 应用开始兴起。基于像 web 、浏览器端、web 服务器以及数据库这种三层架构的应用开始兴起。Java 开始引领整个开发的语言；同时，数据库的技术也蓬勃发展，一个大的数据库可以承受非常高的业务的处理能力。在这个时期，监控类的软件向 apm 这种应用性能管理软件演进。产生比较典型的 ca，或者 quest 等的初代文件。在这个过程当中需要解决的是整个 web 服务器的性能，因为都是通过像 Java 这种语言体系来去构建的，就需要对于这种 Java 的应用去进行代码级别的最终注释以及去关注 Java 应用和数据库连接之间的数据库调用的性能的关系。

到了2005年之后丰富式应用开始兴起。 SOA 怎么架构的、ESB的应用越来越流行。同时虚拟化像 KVM、VMware 这种虚拟化的技术也越来越成熟。在传统的物理机上面会虚拟出非常多的虚机来跑这个应用。同时，三方组件像消息队列、缓存等也越来越多。在这样一个丰富式架构之下，产生的新一代的自动 apm 的组件；在这个时期非常重要的就是做全链路的追踪，因为利用分布式后，应用是如何调试的，这个应用和底下虚拟层的关系如何，是不是因为虚拟层的资源问题导致了整个应用的性能问题，包括应用调用大量的三方组件等。那么这种三方组件，比如消推类有没有问题啊？缓存性能是不是足够的。对于这种三方组件，这个监控也成为这一代 apm 非常核心的能力。

2010年之后，随着整个云源生架构的盛行，首先微服务已经开始兴起，微服务会在原来分布式应用的基础上，把服务拆的更碎，会有成百上千的微服务拆解出来。同时，虚拟化更加彻底，产生了容器，包括 k8s 容器管理平台。同时，三方组件也越来越多的变成了像零服务，比如原来自己搭 radious，而现在会用云上 radious 的服务，自己搭的消息对列会使用更多的云上消息对列的动负，所以整个应用架构就会生长云，基云成为一个云原生的架构。在这种架构之下，对于原来的 apm 软件的需求就提出了更高的要求。首先覆盖的数据面就更加全，从原来单纯的应用层覆盖和一些基础架构的覆盖开始，去覆盖到像容器、k8s等，要覆盖到云服务的性能。同时对于在海量的可观测数据之下，它能够快速去找到定位问题同时提出新的要求。同时，整个可观测的能力也从单纯的运维态，像测试，开发态去进行一个演进，目的就是要去更加快速的去加速业务的创新，让应用的业务迭带快起来，所以说，在这个时期。可观测能力已经成了整个云原生的一个基础设施。

2、什么是可观测

监控软件，APM 软件，可观测，到目前的可观测，是一个演进过程。可观测一定要包含监控的能力及 apm 的能力。但同时也在云原生这个时代提出了一个新的要求。这三者之间的具体关系是什么。

例如，分析一个模型，如果对于这个世界上的事情，从我们是否知道到是否理解的两个维度去进行划分，对于我们知道的且能理解的这个事情就是事实；但针对事实类的事情，在可观测方面其实就是一个监控的事情；比如做运维工作时，一开始要去监控服器上 cpu 的利用率，如果 cpu 上升之后会有一个什么样的后果？那对于这种事情就是监控。去解决的事情就是基于知道要监控什么，然后采集到相应的指标，进行相应的监控这个大盘以及告警。

第二个层次，对于我知道但我还不理解为什么会发生这个事情。这个事情其实就是传统的像 apm 去解决问题，或者就是要去理解为什么会发生这个现象。比如说刚才的 cpu 利用率高，监控监测到了指标的上升，那 apm 就要去回答为什么 cpu 会高。通过采集应用册的链路，能够通过分析链路发现在链路调用过程当中，一个绕框架，它的占用就非常高，就引起了抢占机器或者虚机上的资源，这是通过 apm，通过应用层的分析发现了 cpu 高的原因，那在可观测上这个领域中更进一步就是 cpu 高，这个情况通过去分析采集上来的各种日志，以及像链路及各种指标。可以发现像上海这个地域，比如说，通过这个苹果终端访问的请求产生的日志量是飙升的，这其实就是可观测解决的一个问题。因为首先在事前不知道上海这种维度的组合会导致 cpu 利用率高的问题。事前不可能去建一个告警师，专门去监测上海地域 map 端的访问情况，因为这个是超出认知范围之外的。是要通过去探索能力，去发现能力，在这样维度组合之下，跟其他的维度相比，它产生了相应更高的访问延时。同时通过关联日志数据和指标的数据会发现，这个日志本身的访问延时，本身是因为 log 框架的调用，同时产生大量日志，通过分析日志发现质量有了一个飙升。这样就会发现原来你不知道的可能也不知道为什么会发生这个事情，这其实就是可观测去解决问题。预警的话是另外一个预测的话题。

总结：

• 监控

指标+面板+告警（基础架构）

监控就是关注指标。指标主要是集中在接触架构层的，比如像机器、网络形成的指标，然后通过给这些指标我们建立相应的面板、告警，去监测已知范围能力的事。

• APM

应用链路+诊断工具+定位调优（应用层+用户体验）

apm 通过基于应用层面的这些链路，包括各种内存、线程和诊断工具等，去基于监控发现的问题定位找到根因。为什么会出现监控指标异常。属于是解决为什么发生了这样的问题，可能也会用到应用层、用户体验层的各种链路和监控数据。

• 可观测

日志+链路+指标+事件（全栈）

以应用为中心的关联-AIOps

基于云服务的 DevOps 全流程

可观测更进一步需要去使用日志、链路、指标、事件等全栈的各种可观测的数据云；同时，在海量数据之下，以应用为中心对数据进行关联分析，可能需要用到 elapse 的这种能力，领域分析的能力，去非常快速的把根因找出来。同时提供一个使用用户的界面，可以在这一些可观测数据里面去非常方便找到关联的信息以及相应的异常信息去做探索。基于这些可观测数据之后发现的这些问题，我们能够跟云上的各种云服务进行打通，比如 pass 平台的扩速溶能力，高可用的性能降级能力，能够更加快的去恢复应用，解决应用的问题。这是目前可观测跟以往的 apm 、跟监控相比提出的一个全新的一个挑战。

二、建设可观测体系关键要点

1、可观测数据的采集

（1）全栈

要全栈的一个覆盖，从基础架构、容器层、三方组件、云服务、应用及用户终端都需要去覆盖上面的相应的可观测数据，因为可观测数据还包括每一层都有都可能有指标、链路，以及日志和实践。

（2）统一标准

采集可观测要进行标准的统一。其实是整个业界一直在推进的，比如很多开源标准的盛行。像指标，通过 Prometheus 统一了相应的可观测指标类型，Opentracing、OpenTelemetry 的出现统一了链路。日志等数据化，由于它的结构化程度相对比较低，可能现在还没有相应的开源标准，但整个可观测数据的类型，业界开源的采集，标准和数据类型的标准都已经逐渐成型了。

（3）质量

可观测数据的质量。这也是开源可观测工具和商业化可观测工具相对参与较大的地方。例如，采集一条应用的调用链路，到底采多深；这个调用链路采样的策略是什么；错的、慢的时候是不是能够把它全部采集下来；是不是能够动态的给予一些规则去进行采样策略的调整。都决定了可观测数据采集下来的质量问题。

2、可观测数据分析

（1）关联

可观测数据分析，在海量的数据之下，从什么样的角度去关联起来非常重要。在目前的可观测体系里面，有一个非常好的切入点就是从应用角度。因为首先应用之间它是相互关联，通过调用链可以关联起来，包括微服务之间是怎么调用的。应用、云服务和三方组件之间是什么样的调用关系？这可以通过链路去进行解决。同时调点的话，应用、底下容器层和底下资源层，也可以进行垂直的映射。这样的话，以应用为中心，可以基于横向和纵向形成比较好的可观测数据的关联。出现问题的时候，当我要去定位一个问题，能够从应用角度对这些可观测数据进行统一的分析。

（2）领域知识

在海量数据的情况之下，如何能够更加快速去发现问题，能够更加准确去定位到问题。除了以应用为中心把数据关联起来，另外，就需要怎么去定位分析问题的领域知识。也就是一个工作多年非常有经验的工程师去定位问题和可能刚毕业的工程师，效率是完全不一样的。这背后对于可观测的工具或者产品。非常重要的就是能够不断的去累积这种最佳的排查路径、常见问题的定位决策链路与方法，能把这一套经验能固化起来，就相当于给每个使用可观测系统的团队背后就配了一名非常有经验的工程师，能够不断去看，发现问题在哪里，快速的去把问题根因定位出来，这也是传统的 iopx 的能力。

3、可观测价值输出

（1）统一

可观测价值输出，可观测相应的可能需要覆盖各个层，各个应用相关的层，在每一层都有相应不同的可观测数据。目前的现状就是工具都特别散，如何能够把这些可观测工具产生数据统一的展现出来，这是一个比较大的挑战。目前在业界也有相应的像 Grafana 等方式能够统一的去把可观测的结果去进行展现，有可观测数据的统一相对来说是比较难的一件事，但是结果的统一，呈现统一是可以做到的。这也是越来越多的团队在做像统一的监控大盘统一的界面去做的事情。

（2）协作

另外一方面，借助像钉钉，企业微信这种协作平台，能够更加高效的进行问题的发现、处理、跟踪以及排班、升级等。总流程就涉及到了现在比较流行的另外一个运维的方式叫 charalks ，这种写作平台的运作方式。

（3）云服务联动

同时借助协作平台，能够跟云上的各种云服务进行联动化。比如，扩收容的服务、信流降级服务联动去更快的把问题进行一个闭环。

三、云原生可观测性覆盖数据

可观测数据各层都可能产生指标

1、cpmemory 在技术架构，应用层的黄金三指标向用户体验，有用户体验册的指标。指标目前业界的标准公修是已经开始形成，都可以通过标准的方式去进行存取和读取。

2、Tracing 基础架构、网络层有相应的网络的 Tracing，应用层有 OpenTracing， OpenTelemetry 这种 Tracing 的方式。这种 Tracing 方式在用户体验其实也要像用户的 section，用户的动作相关联的这种 Tracing。

3、Log 这一类就更像SysLog、应用的日志，包括我们制定的日志。数据非常多，而且数据类型也比较多的情况下，有个可观测体系，去遵循开源开放方式就非常繁琐。指标产生，尽量可以以建融的格式去进行相应的产生和读取；我的Tracing尽量的是可以Opentracing、OpenTelemetry方式去进行相应的统一。像日志、显示，能够通过 Grafana 的方式统一的把各种可观测的数据源进行集成，然后统一进行展现分析。这是在可观测数据去建设时非常重要的一点——开源开放。

四、ARMS3.0云原生可观测平台

在阿里云上也提供了一站式可观测的平台称为 ARMS，就是利用实时监控服务。 ARMS 其实是产品家族，包含了底下的东盘产品。比如，针对于基础价格层有相应的 Prometheus 服务，全托管的 Prometheus 的服务。对于 ecs ，vbc，包括容器里面的 caps ，ack；包括云服务，各种云服务 slb， ids 的这种云服务的监控以及三方组件的监控都可以通过Prometheus 服务来进行相应的监控。对于应用层来说，提供了应用监控，就是自研的 Java 探针。这是在可观测数据质量里进行的非常多工作，相比开源也是有非常大的提升，但同时也提供内容，最终就是如果使用的是开源的 sdk，或者是探针，通过利用这个方式，也可以同样上报到监控平台。在用户体验测，通过移动监控，前端监控、云波测等去覆盖用户在各个渠道上的用户体验的性能。对于这样一个全平台可观测能力的覆盖。还建立了一些平台级共用的能力，比如统一的 ARMS 报警中心。对于各层，各个产品采集的数据报警信息进行统一的报警。对于各个产品采集的可观测数据进行相应的 AIOps 分析跟发现。直接呈现 Insights 发现结果。还有 Grafana 的托管服务，这是开源托管服务。提供相应的统一的界面，那么不管你的数据是通过 arms 接进来，包括上报到 arms 的 Prometheus 里面还是使用阿里云上，比如日志服务、使用 Elasticsearch 等各种数据的服务，都可以通过 Grafana 进行统一的数据可观测数据的呈现，统一的大盘，统一的监控。同时通过这种方式，提供用户相应的 AIOps 能力，提供给用户云定一体的报警处理能力，以及我们可以跟阿里云上的这款 ARMS 的平台和这个高可用的服务联动提供一个 CloudOps 能力。

五、云上 ARMS 产品演示

登录阿里云，搜索 ARMS 可得到 ARMS产品

进入控制台，最左侧为 ARMS 产品的能力和模块

• 应用监控、前端监控是传统的 apm 的能力采集链路，分析应用性能

• Prometheus 监控——是应用监控简单监控指标性的数据。同时也存到了 Prometheus 监控里。Prometheus 监控也能够用于容器 k8s 和各种云服务监控数据的统一。

• App 监控是移动端的能力，Kubernetes 监控是基于 eBPF 这种方式进行容器的网络层以及应用层上 workload 的一个监控。

• 云拨测——通过遍布全国各地拨测的点去对应用进行主动的侦测。

• Insights 就是 ARMS 的能力可以去实时的给予我们采集到的可观测这数据去进行相应的 Arms 风险帮助在数据里面发现，比如异常的指标点，然后基于异常的指标点进行全局分析、关联、定位最终指向到具体的，比如说统计链路以及代码级别的根因能力。

• 告警——管理的平台就是 ARMS 的告警管理平台，告警 ARMS 管理平台可以采集到 arms 平台的告警，包括自定义的、 OpenFalcon、

Nogios、Zabbix 等各种外部的数据源的报警信息都可以统一的集成进来进行统一的管控，统一的分析。同时有通过添加钉钉的机器人，就可以在钉群里面进行一个整个闭环的一个告警信息的一个处理。

• Grafana 托管服务——Grafana 托管服务可以通过基层进行各种数据源和可观测数据统一数据管控

六、Grafana + Prometheus 构建开源统一的可观测体系

通过 Grafana + Prometheus 两款开源的托管类的产品怎样去构建属于自己的可观测系统。因为像 arms 全栈的产品可能很多里面的能力目前企业已经具备，我们可能是采用 arms 里面的某些产品，比如只用应用监控，或者只用潜能监控等某些部分能力。但是整个可观测系于对于企业，也希望去开源区构建自己的可观测系统。如何基于 arms 已有的产品能力，以及我们开源 arms 上的开源托管的方式去构建自己可观测的系统。

arms 目前提供 Prometheus 的服务其实是开箱即用的。已经能够采集到哪些可观测数据或者指标数据。第一个就是云服务的监控就是阿里云上的各种云产品，监控数据现在都已经可以放到 Prometheus 的数据里面。一键集成进去。阿里云上的 ecs 集群，ack 集群，对于集群的监控数据也是一键集成到 Prometheus 中。在这些集群上面，比如三方组件，上面跑的各种应用 Java 应用，或者多语言的应用，只要通过Opentracing、OpenTelemetry 的 sdk 接入或者通过自研的才能接入。这些应用监控应用层的 apm 数据也都是一键集成到 Prometheus 中。同时也可以通过开源的 sdk 方式把业务一些制定的指标写到 Prometheus 里。这都是相应的一键集成开箱即用的。在 Prometheus 里面可以囊括阿里云中的数据。同时 Grafana 支持跟阿里云的日志服务对接，日志服务这种前端监控将 PV、UV、用户体验的数据也可以纳入进来。同时 Grafana 对接了阿里云上的 ClickHouse、Elasticsearch、MySQL、MongoDB 等各种数据源。通过统一的 Grafana 界面，就可以实现相应的统一的大盘的建设，统一的告警。同时通过相对来说比较统一的查询语言。去进行可观测数据的这个探索。