作者：西杰 & 白玙

可观测的前生今世

系统的可观测与故障可分析作为系统运维中重要的衡量标准，随着系统在架构、资源单位、资源获取方式、通信方式演进过程，遇到了巨大挑战。而这些挑战，也在倒逼着运维相关技术发展。在正式开始今天的内容前，我们来讲讲可观测的前世今生，纵观整个运维监控发展历程，监控与可观测已经发展了近 30 年。

上世纪 90 年代末，随着计算从大机（mainframe）逐渐转移到桌面电脑，client-server 架构的应用开始盛行，大家开始关注网络性能和主机资源。为了更好的监控这种 CS 的应用，第一代 APM 软件诞生。运维团队在这一时期看重与网络性能、主机性能，因为此时的应用架构还非常简单。此时，我们还称这些工具为监控工具。

进入到 2000 年，互联网飞速发展，浏览器成为新的用户界面。应用演进成为基于浏览器的 Browser-App-DB 的三层架构，同时 Java 作为企业级软件的第一编程语言开始盛行，编写一次、到处运行（write once，run anywhere）的理念，极大的提升了代码的生产力，然而 Java 虚拟机也屏蔽了代码运行的细节，使得调优排错变得愈加困难， 所以对于代码级的跟踪诊断和数据库的调优成为新的关注点，从而诞生了新一代的监控工具 APM（应用性能监控）。

2005 年之后，分布式应用成为很多企业的第一选择，像基于 SOA 架构、ESB 的应用大行其道。同时，虚拟化技术逐渐盛行，传统服务器这个物理单位逐渐淡化，变成了看不见、摸不到的虚拟资源模式。像消息队列、缓存这样的三方组件也开始应用在生产环境中。在这样的技术环境下，催生出新一代 APM 软件，企业开始需要进行全链路追踪，同时监控虚拟资源和三方组件监控，这样就衍生出了新一代 APM 的核心能力。

到了 2010 年之后，随着云原生架构开始落地实践，应用架构开始从单体系统逐步转变为微服务，其中的业务逻辑随之变成微服务之间的调用与请求。同时虚拟化更加彻底，容器管理平台被越来越多企业接受，三方组件也逐渐演变成云服务，整个应用架构成为云原生架构。服务的调用路径变长，使得流量的走向变得不可控，故障排查的难度增大，需要一种全新的可观测能力，通过覆盖全栈的各种可观测数据（指标，日志，链路，事件）在开发测试运维的全应用生命流程进行持续的分析。

可以看到，可观测能力成为云原生的基础设施。整个可观测能力从单纯的运维态开始向测试开发态演进。可观测的目的也从支撑业务正常运行进一步扩展到加速业务创新，让业务快速迭代起来。

监控 & APM & 可观测的认知同异

从上述历程，我们可以看到从监控到 APM 到可观测是个不断演进的过程。接下来，我们讲讲这三者之间的具体关系。为了更好的讲解，这里先引入一个经典认知模型。对于世界万物，我们通常会按照“知不知道”（awareness）以及“理不理解”（understanding）两个维度进行划分，即“感知”与“理解”。

那么，首先对于我们知道且能理解的事情，我们称之为事实。落到刚才讨论的话题中，这一部分对应的就是监控。比如进行运维工作时，一开始时候就会设计去监控服务器的 CPU 利用率，这个利用率不管是 80% 还是 90%，都是一个客观事实。这就是监控解决的事情，即基于知道要监控什么，制定采集相应指标，并建立监控大盘。

接下来，就是我们知道但不理解的事情。比如监控到 CPU 利用率达到 90%，但是为什么会到这么高，是原因什么导致的，这就是一个查证的过程。通过APM可以采集并分析主机上的应用性能，发现在应用链路调用过程中某个高延时的 log 框架，从而引起了主机上的 CPU 利用率飙升。这就是借助 APM 通过应用层分析去发现 CPU 利用率高的背后原因。

然后，就是我们理解但不知道的事情。依旧是 CPU 利用率高这个场景案例，如果通过学习历史数据和关联事件预测到未来的某个时刻会出现 CPU 利用率飙升，就可以实现预警。

最后，就是我们不知道且不理解的事情。还是上面的例子，如果通过监控发现 CPU 使用率飙升，通过 APM 发现应用日志框架所致。但进一步，如果分析这一时间段内用户的访问数据，发现在上海地域，通过苹果终端访问的请求，相比其他的情况响应时长要高 10 倍，而这种类型的请求由于日志框架的配置产生了海量的 Info 日志，导致了某些机器的 CPU 飙升。这就是一个可观测的过程。可观测是需要去解决你事先不知道（来自上海的苹果终端访问性能问题）也不理解的事情(错误配置日志框架产生海量 info 日志）

简单总结一下，在监控领域我们关注指标，这些指标可能集中在基础架构层，比如说机器、网络的性能指标。然后基于这些指标建立相应看板以及告警规则去监测已知范围里的事情。在监控发现了问题之后，APM 通过基于应用层面的链路以及内存和线程等诊断工具，去定位监控指标异常的根因。

可观测以应用为中心，通过将日志、链路、指标、事件等各种可观测数据源进行关联、分析，更加快速、直接地找出根因。并提供一个可观测界面，让用户可以灵活自由的在这些可观测数据中进行探索与分析。与此同时，可观测能力与云服务打通，即时强化应用的弹性扩缩容、高可用等能力，在发现问题时能够更加快地解决相关问题，恢复应用服务。

建设可观测体系关键要点

可观测能力带来了巨大业务价值的同时，也带来了不小的系统建设挑战。这不仅仅是工具或技术的选型，更是一种运维理念。这其中包括可观测数据的采集、分析以及价值输出三个部分。

可观测数据采集

目前业界广泛推行的可观测数据包含三大支柱：日志事件（Logging）、链路追踪（Tracing）、指标监控（Metrics），其中存在一些共性需要关注。

1）全栈覆盖

基础层、容器层、上方组建云服务应用，以及用户终端相应可观测数据以及与之对应的指标、链路、事件都需要被采集。

2）统一标准

整个业界都在推进标准统一，首先是指标（metrics），Prometheus作为云原生时代的指标数据标准已经形成了共识；链路数据的标准也随着 OpenTracing 和 OpenTelemetry 的推行而逐渐占据主流；在日志领域虽然其数据的结构化程度较低难以形成数据的标准，但在采集存储和分析侧也涌现了 Fluentd，Loki 等开源新秀；另一方面，Grafana 作为各种可观测数据的展示标准也愈加明朗。

3）数据质量

数据质量作为容易忽视的重要部分，一方面，不同监控系统的数据源需要进行数据标准的定义，确保分析的准确性。另一方面，同个事件可能导致大量重复指标、告警、日志等。通过过滤、降噪和聚合，把具备分析价值的数据进行分析，保证数据质量的重要组成部分。这也往往是开源工具与商业化工具差距相对较大的地方。举个简单例子，当我们采集一条应用的调用链路，到底采集多深？调用链路采样的策略是什么样的？发生错、慢时是不是能够全部采下来？是不是能够基于一定规则对采样策略进行动态调整等等，都决定了可观测数据采集的质量。

可观测数据分析

1）横纵关联

在目前的可观测体系里，应用是非常好的分析切入角度。首先，应用与应用之间是相互关联，可以通过调用链关联起来。其中包括微服务之间是如何调用，应用与云服务以及三方组件如何调用，都可以通过链路进行关联。同时，应用与容器层、资源层也可进行垂直映射。以应用为中心，通过横向纵向形成全局可观测数据关联。当出现问题需要进行定位时，能够从应用角度进行统一分析。

2）领域知识

面对海量数据，如何更快速的发现问题，更准确定位问题。除了通过以应用为中心的数据关联，还需要去定位分析问题的领域知识。对于可观测工具或产品而言，最重要的就是不断累积最佳排查路径、常见问题定位、根因的决策链路方法，并把相关经验固化下来。这相当于为运维团队配备经验丰富的运维工程师，去快速发现问题，定位根因。这个也是不同于传统的 AIOps 能力。

可观测价值输出

1）统一展现

上面提到可观测需要覆盖各个层次，每层都有相应可观测数据。但目前可观测相关工具非常零散，如何将这些工具产生的数据统一展现出来，成了比较大挑战。可观测数据的统一其实是相对较难的事情，包括格式、编码规则、字典值等问题。但数据结果统一呈现是可以做到的，目前主流的解决方案是使用 Grafana，搭建像统一监控大盘。

2）协作处理

在统一展现以及统一告警之后，如何借助像钉钉、企业微信等协作平台能够更加高效地进行问题发现并处理跟踪的 ChartOps，也逐渐成为刚需。

3）云服务联动

可观测能力成为云原生的基础设施，当可观测平台在发现并定位问题之后，需要与各种云服务快速联动，迅速进行扩缩容或负载均衡，从而更快的解决问题。

Prometheus + Grafana 实践

得益于云原生开源生态的蓬勃发展，我们可以轻而易举地建设一套监控体系，比如使用 Prometheus + Grafana 搭建基础监控，使用 SkyWalking 或 Jaeger 搭建追踪系统，使用 ELK 或 Loki 搭建日志系统。但对运维团队而言，不同类型可观测数据分散存储在不同后端，排查问题仍需在多系统之间跳转，效率得不到保证。基于以上，阿里云也为企业提供了一站式可观测平台 ARMS（应用的实时监控服务）。ARMS 作为产品家族，包含了不同可观测场景下的多款产品，比如：

• 针对于基础架构层，Prometheus 监控服务对包括 ECS、VPC、容器在内的各类云服务以及三方中间件进行监控。

• 针对应用层，基于阿里云自研 Java 探针的应用监控全面满足应用监控需求。相较于开源工具，在数据质量等方面非常大的提升。并通过链路追踪，即使使用开源 SDK 或探针，也可以将数据上报到应用监控平台。

• 针对用户体验层，通过移动监控、前端监控、云拨测等模块，全面覆盖用户在不同终端上的体验与性能。

• 统一告警，对于各层采集的数据、告警信息进行统一告警以及根因分析，直接通过Insight呈现发现结果。

• 统一界面，不管是ARMS、Prometheus的上报数据，还是日志服务、ElasticSearch、MongoDB 等各种数据源，都可以通过全托管 Grafana 服务进行统一的数据可观测数据呈现，建立统一的监控大盘，并与阿里云各种云服务进行联动，提供 CloudOps 能力。

上述提到 ARMS 作为一站式产品，具备非常多的能力。目前企业已自建部分与ARMS类似能力，或采用 ARMS 中的部分产品，比如应用监控、前端监控。但完整的可观测系统对于企业而言，依旧至关重要，并希望基于开源去构建符合自身业务需求的可观测系统。在接下来的示例中，我们着重讲解 Prometheus + Grafana 如何去构建可观测系统。

数据快速接入

在 ARMS 中，我们可以快速建立一个 Grafana 独享实例，ARMS Prometheus、SLS日志服务、CMS 云监控数据源都可以非常便捷的进行数据同步。打开 Configuration，可以快速查看相应数据源。在时间快速接入各种数据源的同时，尽可能降低日常数据源管理的工作量。

预置数据大盘

在数据完成接入后，Grafana 自动帮大家创建好相应数据大盘。以应用监控以及容器监控大盘举例，像黄金三指标、接口变化等基础数据都将默认提供。

可以看到，Grafana 虽然帮助大家把各种数据看板搭建起来，但看到的依旧是零散大盘。在日常运维过程中，还需要基于业务域或基于应用创建统一大盘，能够将基础架构层、容器层、应用层、用户终端层的数据都放到同一个大盘中进行展现，从而实现整体监控。

全栈统一大盘

在建立全栈统一大盘时，我们按照用户体验、应用性能、容器层、云服务、底层资源等维度进行准备。

1）用户体验监控

常见的 PV、UV 数据、JS 错误率、首次渲染时间、API 请求成功率、TopN 页面性能等关键数据都会在第一时间呈现。

2）应用性能监控

以黄金三指标为代表的请求量、错误率、响应时间。并根据不同应用、不同服务进行区分。

3）容器层监控

各个 Pod 的性能、使用情况，同时也列出这些应用上跑的由哪些 department 创建的。这些 deployment 相关的 Pod 性能信息都呈现在这一块。

4）云服务监控

此外，就是相关的云服务监控，这里以消息队列 Kafka 举例，像消息服务常见的相关数据指标如消费量堆积、消费量等数据。

5）主机节点监控

针对整个主机节点，CPU、所运行的 Pod 等数据。

这样子，这张大盘就覆盖了从用户体验层到应用层到基础架构容器层的整体性能监测情况。更加重要的是整个大盘包含着所有微服务的相关数据。当切某个服务，服务相关联的性能数据都将独立展现出来。在容器、应用、云服务等不同层面都进行过滤。这里稍微提一下是怎么做到的，当 Prometheus 监控去采集这些云服务时，会顺带把云服务上的 tag 都采集下来。通过对 tag 进行打标，就可以把这些云服务基于不同业务维度或不同应用进行区分。在做我们统一大盘的时候，一定会遇到非常多的数据源管理问题。这里我们提供了 globalview 能力，把这个用户名下所有的 Prometheus 实例都汇聚到一起，统一进行查询。不管是应用层的信息，还是云服务的信息。

借助上面的场景，我们抛砖引玉提出可观测性平台设计方向：基于系统和服务观测的角度把不同数据在后端融合分析，而不是刻意强调系统支持可观测性三种数据的分别查询，在产品功能和交互逻辑上尽可能对用户屏蔽 Metrics、Tracing、Logging 的割裂。建立完整可观测闭环，从事故前异常发现、事故中故障排查到事故后的主动预警监控，为业务持续监控、优化服务性能提供一体化平台。

点击此处，回看精彩视频演讲，了解更多可观测实战干货 ！