1.2 可观测性数据

可观测性将成为数据驱动型决策的强有力支撑，可观测性中的一切都基于可观测性数据。那么，可观测性数据是什么？应该如何建立统一的可观测性数据模型呢？本节将基于可观测性数据的类型和来源来介绍如何构建统一的可观测性数据模型，以及在实战场景下这些数据是如何联合发挥最大价值的。

1.2.1 可观测性数据的类型

通过可观测性可以轻松地了解一个系统的运行情况，在出现问题时也能快速得知其中的原因，并快速解决问题。因此，需要对系统进行必要的数据采集。

可观测系统中的数据可以分为多种类型，如链路数据、指标数据、日志数据、事件数据、诊断数据和快照数据，每种类型的数据都有特定的含义和使用场景。

在2017年的分布式追踪峰会之后，指标、链路和日志作为可观测性的三大支柱受到了业界的广泛认可。但只有这3类数据往往不足以完整地展现系统状态，因此还需要采集事件数据、诊断数据和快照数据。事件数据可以更直接地描述系统的运行状态，尤其是资源和基础设施的运行状态。诊断数据通常能帮助用户发现系统存在的问题。快照数据通常用于排除故障，在系统崩溃时将内存镜像写入Dump文件中，用于后续分析。

基于可观测性的基础数据，可观测系统可以实现指标监控、链路追踪、故障分析、系统诊断、智能告警、故障预警、容量规划等一系列功能，如图1-15所示。

1.指标

指标（Metrics）是在运行时采集的用于衡量系统当前状态的度量，如请求量、请求耗时的平均值、错误请求的个数等。

指标包括指标的定义和指标的维度：指标的定义指明这是一个什么指标；指标的维度指明指标计算的维度。例如，有一个请求耗时指标，指标的维度包括服务名A和接口B，则这个指标表示服务A中接口B的请求耗时。指标是非常重要的可观测性数据，系统中的每个组件都需要采集相应的指标，这些指标将作为衡量系统状态和性能的重要数据。

指标是对系统中的某类信息的统计聚合。例如，证券市场上的每只股票都会定期公布财务报表，通过财务报表中的营业收入、净利润、毛利润、资产和负债等一系列数据可体现过去一个财务周期中公司的经营状况，这就是一种信息聚合。Java自带了一种基本的度量，就是由虚拟机直接提供的JMX，如虚拟机内存的大小、不同内存分区的使用情况、峰值的线程数、垃圾收集的吞吐量和频率等都可以从JMX中获得。通过对指标进行监控，就可以简单地了解一个系统的运行情况，同时可以对指标设置告警，如某些指标达到风险阈值时触发事件，以便自动处理或提醒相关人员介入。

2.链路

链路（Trace）是对系统中每个调用请求的追踪。

链路数据可以还原一个请求完整的调用路径及每个节点的状态。通过系统中所有的链路数据，可以还原系统调用完整的拓扑图，以及了解系统中组件与组件之间的依赖和调用情况，通过拓扑图能够一目了然地了解系统中存在风险的节点。

单体架构追踪的范畴基本上只局限于栈追踪（Stack Tracing），当调试程序时，在IDE（Integrated Development Environment，集成开发环境）中设置断点，显示的Call Stack视图中的内容便是链路追踪；在编写代码时，处理异常调用了Exception：：printStackTrace()方法，该方法输出的堆栈信息也是链路追踪。

在微服务时代，链路追踪不再局限于调用栈。一个外部请求需要内部若干服务的联动响应，这时完整的调用轨迹将跨越多个服务，同时包括服务间的网络传输信息与各个服务内部的调用堆栈信息，因此分布式系统中的追踪也被称为全链路追踪或分布式追踪。追踪的主要目的是排查故障，如分析调用链的哪一部分、哪个方法出现错误或阻塞，以及输入/输出是否符合预期等。通过链路追踪也可以了解一个接口或一个服务的依赖情况，通过链路形成的拓扑图可以表明整个系统的依赖情况。

3.日志

日志（Log）通常是带有时间戳的文本记录。

日志通常是由研发人员在编写代码时设置的，具有特定的业务含义。通过查看日志能快速定位问题。日志可以通过链路标记和链路数据进行关联，从而实现数据的联动。

日志的职责是记录离散事件，通过这些记录事后分析程序的行为，如曾经调用过什么方法、操作过哪些数据等。打印日志被认为是程序中最简单的工作之一，调试问题时经常有人说“当初在这里打印日志就好了”。输出日志的确很容易，但采集和分析日志可能很复杂，因为面对成千上万个集群节点、迅速滚动的事件信息和TB级别的文本，传输与归集都不简单。对于大多数程序员来说，分析日志也许就是最常遇见且最有实践可行性的“大数据系统”。

4.事件

事件（Event）用来描述某个对象瞬间的、非持续性的变化。

在可观测系统中加入事件能更直接地描述系统的运行状态，尤其是资源和基础设施的运行状态，从而更快地发现问题和解决问题。通常，一次部署、一次配置变更和一次熔断触发都称为事件。容器重启是指容器在某个时刻执行了重启操作，这是一个事件。如果某个服务的容器频繁重启，即某个容器重启事件频繁发生，这就是一种不正常的现象。

5.诊断

诊断（Profiles）通常用来排查性能问题，如延迟问题、CPU异常飙升等。

在系统中加入丰富的诊断数据，可以更深入地对特定系统问题的根因进行分析。通过这些诊断数据，能够发现现网系统存在的特定性能问题，了解资源在系统运行时是如何分配和使用的。尤其是在云原生时代，容器技术的全面应用使得在对云原生系统进行优化和资源分配时，对资源的全面理解变得越来越重要。

例如，当调用链显示某些数据存在延迟问题时，通过对诊断数据进行分析，可以更加深入地挖掘和了解延迟问题是如何发生的、发生的根本原因，以及了解所编写的代码对资源的实际消耗情况。

常见的诊断数据有CPU诊断数据（CPU Profilers）、内存诊断数据（Heap Profilers）、GPU诊断数据（GPU Profilers）、互斥锁诊断数据（Mutex Profilers）、I/O诊断数据（I/O Profilers）和JVM诊断数据（JVM Profilers）等。

6.快照

快照通常是指系统快照，也就是Dumps，核心的Dump文件被用于排除程序故障。

系统或应用软件会根据一些配置把进程崩溃时的内存镜像写入Dump文件中，用于后续分析。由于现网系统在发生故障时通常以快速恢复提供的服务为首要目标，但是有些问题在测试环境下很难复现，因此采用保存现场快照数据的方式能够为后续分析故障根因提供支持。

例如，从JVM的Dump文件中能够获取堆对象的统计数据，以及对象相互引用的关系。通过对这些数据进行分析，可以快速定位内存泄漏的问题。

但是在云原生环境下，收集Dump文件的难点在于存储和网络方面。由于大型集群的核心Dump文件非常大，因此传输和存储取决于集群的存储是如何连接集群节点的。例如，处理密集型的应用程序最终可能会生成GB级别的核心Dump文件。

通过采集系统中的这些基础数据，可以为可观测系统提供全面的、详细的数据来源。在衡量一个系统中的数据是否足够全面时，可以通过在故障发生时支撑分析故障根本原因的数据是否已经足够来判断。如果在故障发生时无法通过可观测系统中的已有数据来分析故障和排除故障，就需要调整数据采集方案，从而更加全面地采集数据。

可观测性数据的来源有云和基础设施、系统和容器、中间件、业务框架、业务服务。云和基础设施的可观测性包括机房的网络、磁盘等；系统和容器的可观测性包括虚拟机、Kubernetes集群等；中间件的可观测性包括数据库、消息队列等；业务框架的可观测性包括Spring框架、Dubbo框架等；业务服务的可观测性包括业务自定义的指标、事件，如越权访问。

只有全面采集数据才能呈现系统完整的运行状态，如图1-16所示，可观测系统将所有的可观测性数据输入一个平台。将不同来源的数据和不同类型的数据进行关联，可以使数据发挥更大的作用。使用统一的数据模型可以快速对不同的数据进行联合分析。

本节介绍了可观测性数据的类型和来源，但现有的数据和工具仍然无法完全满足需求，未来可能还会加入更多的可观测性数据。另外，不同类型的数据和不同应用的可观测性数据的采集与测量方法各有不同，不仅需要花费大量的系统资源和研发资源，还需要根据具体的业务架构对数据进行权衡和取舍。

1.2.2 实战场景下运维人员观测的数据

最先应用监控系统的就是运维领域，尤其是Site Reliability Engineering：How Google Runs Production System（《SRE：Google运维解密》）与Real-World SRE：The Survival Guide for Responding to a System Outage and Maximizing Uptime（《SRE生存指南》）这两本书，提炼出了传统监控的方法论，为运维监控系统提供了宝贵的指导。本节主要介绍在可观测系统的实战场景下，运维人员的职责和从运维角度观测的数据。

在传统的企业中，通常由运维人员来使用和维护监控系统。

保障业务的稳定运行、维护系统的安全性是运维人员的首要职责。在传统的监控系统中，运维人员的工作通常分为以下3个阶段。

• 通过监控系统查看系统指标，如CPU的使用率、内存的使用率。

• 对指标设置性能基准，如CPU的使用率性能基准达到多少时需要运维人员介入处理。

• 根据基准在告警系统中设置告警阈值，通过及时处理告警来保障系统的稳定性。

传统的监控系统采用分层原则搭建，运维人员需要同时使用多套监控系统来监控不同层次的组件、应用，或者使用不同的监控系统采集不同类型的数据。大多数问题还应依赖运维人员的经验，通过对指标设置告警阈值来分析问题、查找出现问题的原因。

在云原生时代的可观测系统中，无法通过这些独立的监控系统来排查问题，一些深层次的问题甚至无法通过监控系统来暴露。传统的监控系统对于微服务架构中复杂的调用链路和相互依赖问题分析常常束手无策。遇到问题需要研发人员和运维人员一起进行长时间的现网环境排查，但如果要快速恢复现网运行，就会导致问题无法重现，更无法继续排查。

这时就需要运维人员转变职责，和研发人员甚至产品团队一起搭建一个统一的可观测系统。可观测系统需要融入研发与业务的视角，采集比原有监控数据更全面且可以相互关联的数据。

在可观测系统中，运维视角的转变可以分为以下3个方面。

（1）从被动监控到主动发现

传统的监控往往先由运维人员通过告警感知到系统异常，再由人工介入排查问题。而主动发现通常由排错、剖析和依赖分析3个部分组成。排错，即运用数据和信息诊断出现故障的原因；剖析，即运用数据和信息进行性能分析；依赖分析，即运用数据和信息厘清系统中的模块关系，并进行关联分析。

无论是否发生告警，主动发现都会根据系统的运行情况进行诊断分析，并将分析结果通过指标展现，以便指明系统实时的运行状态。在主动发现过程中，如果发现了系统异常情况，就会对系统中相关联的数据进行分析，如通过相关的性能分析获取可能发生异常的具体场景。

主动发现可以提前预测系统中潜在的风险，但需要运维人员和相关的研发人员根据实际的使用情况不断调优来提高主动发现的能力。

（2）从关注单一指标到关注系统整体状态

单一指标偶然的波动对于系统整体来说可能没有很大的影响，但也有可能是系统中深层次的一些问题引发的联动效应。当单一指标异常时，不应该仅仅将关注点放在这个指标上，而应该从整体视角观测系统的运行情况，相关数据是否存在异常，对现网偶现疑难问题的排查非常关键。

可观测系统中的数据之间是可以相互关联的，不是割裂的，因此可以很便捷地建立某个数据与其他关联数据的关系，从而快速了解当前系统的整体状态。

（3）通过理解业务提供更全面的可观测性

需要采集什么数据、如何设计数据模型、数据之间如何建立关联，这些都要求对整个业务架构和业务场景具有全面且深刻的理解。运维人员应该和研发人员甚至产品团队、架构师共同进行可观测系统的设计，从而最大限度地发挥可观测系统的价值。

在可观测系统中，所有数据都是一体化、相互关联的，很多数据也是具有业务含义的。这就需要运维人员具备从业务视角思考问题的能力，实现运维从技术到业务的提升，从而提高预防和事故应对，以及保证业务连续性的能力。

对于从运维角度观测到的数据，Google提出的运维方法论提到了4个黄金指标在监控系统中的重要性，具体如下。

• 吞吐率：应用的请求速率，一般为每秒的请求次数。

• 错误率：应用的请求中有多少出现了错误，出现错误意味着行为不符合预期。

• 响应时间：应用的请求在多长时间处理完成了，如果时间过长就会严重影响用户体验。

• 饱和率：当前应用的繁忙程度，主要强调最能影响服务状态的受限制的资源，如磁盘I/O、内存等。

黄金指标对于系统监控来说具有很好的指导意义。运维人员通过对黄金指标设定不同等级的服务质量目标可以及时获取系统的异常情况。但是自动化的提升和海量数据的采集为运维人员的工作带来了巨大的挑战。运维人员需要在海量的指标中提取出关键数据，以及对海量的告警进行降噪，否则很快就会被淹没在告警风暴中。通过转变运维职责，运维人员对业务和整个系统就会有更深入的了解，不是只对黄金指标设置服务质量目标，而是从业务目标层面对整体的服务质量目标进行设置。

在传统的监控系统中还需要运维人员根据黄金指标的异常情况对系统进行分析，并找到出现问题的根本原因。将可观测性数据和系统中的其他数据进行结合不仅可以自动分析异常指标、输出系统诊断情况，还能够高效地协助运维人员发现系统存在的问题和潜在的风险。

在传统的监控系统中，数据之间是割裂的，运维人员往往只关心基础设施和系统层面的数据，并不会深入理解业务和组件层次的数据。

在可观测系统中，可观测性要求数据具备统一的数据模型、是相互关联的、能进行统一分析和计算。运维人员不再只观测单一的指标数据，而是从整体上对系统的所有数据进行观测。

本节详细介绍了运维人员在可观测系统中职责和关注点的转变，这种转变对于运维人员来说既是挑战又是机遇。今后运维人员应该更加深入地了解和参与业务架构活动，以便搭建统一高效的可观测系统。

1.2.3 实战场景下研发人员观测的数据

可观测系统强调系统中数据的整体性，不只运维人员需要关注，研发人员也需要深度参与（研发人员通过可观测系统对系统性能进行优化）。

本节主要介绍在可观测系统实战场景下，研发人员的职责和从业务角度观测的数据。

传统的监控系统由专门的运维人员负责，研发人员通常不会关注。但是在可观测系统中，研发人员也需要参与，因为研发人员只有肩负对应的职责，才能实现可观测系统的价值。研发人员的职责包括如下几点。

（1）实现业务系统的可观测性

可观测系统需要研发人员和运维人员共同参与搭建，研发人员需要深入理解如何监控他们负责的应用程序，同时架构师在业务系统设计之初就要考虑系统的可观测性。在面对用户更高的期望和更严格的要求时，研发人员必须更快地排除故障并找到出现问题的根本原因。

（2）参与制定可观测性的服务质量指标和服务质量目标

业务指标与业务息息相关，业务指标的服务质量指标和服务质量目标需要研发人员共同参与制定。关键的业务指标可能是在线用户数、日均订单数等，这些指标和业务息息相关，不仅需要研发人员关注，还需要研发人员在业务系统中提供这些指标的可观测性。

（3）深度参与数据处理、数据分析、数据编排能力的建设

在数据处理、数据分析、数据编排的能力建设上，由于部分运维人员编写代码的能力不足，因此需要研发人员高度参与。另外，数据之间存在关联关系，相关研发人员的理解更深刻，能够为数据模型提供更有价值的信息。

从业务的角度来看，可观测性数据不同于运维视角的数据，研发人员更加关注的数据主要有关键业务指标、关键业务追踪和洞察用户真实体验。

（1）关键业务指标

在SRE中，被称作黄金指标的4个指标分别是吞吐率、错误率、响应时间和饱和率。关键业务指标不同于黄金指标，这些指标与业务紧密相关。针对电商业务，关键业务指标可能包含订单数、订单成功率和成交额等；而针对社交业务，关键业务指标则可能是在线用户数、新动态数等。关键业务指标需要和应用指标建立起关联关系，通过关键业务指标监控发现异常时能够进一步定位到对应的应用异常，实现问题的进一步处理。例如，订单数突降，其对应的订单应用的吞吐率、错误率和响应时间可能会发生异常。

（2）关键业务追踪

基于全链路追踪功能，构建完整的服务关系调用拓扑，不仅有助于对关键业务场景的性能进行全链路追踪，还可以协助关键业务提升性能。例如，交易类业务，通过一些业务ID追踪其在各个应用上的执行过程，便于定位分析一些异常业务交易。如果支付业务出现异常，则可以根据用户反馈的支付订单ID进行进一步的分析。

（3）洞察用户真实体验

可观测系统端到端地全面追踪用户在应用上的访问行为及真实体验。通常，可观测系统的关注重点都在后端服务，但是服务端没有错误信息不代表用户在客户端的体验是正常的。在客户端，如App、小程序、H5页面，通过采集全链路的数据，包括用户请求在客户端实际体验的性能情况、控件操作的延迟情况、业务访问情况、资源使用情况，可以更加全面地了解用户的实际使用体验。

可观测系统可以为研发人员提供的价值包括提升系统架构的可见性、提高排除故障的效率、提供更好的研发质量，具体如下。

（1）提升系统架构的可见性

微服务架构中不仅具有庞大的节点群和服务群，还会使用众多的中间件，以及和第三方平台进行交互。在微服务架构的研发团队中，很多研发人员往往只负责其中部分服务的开发，没有全面了解整个系统架构。通过可观测系统可以更好地了解系统架构的整体情况。在可观测系统中，研发人员可以轻易获取系统运行的整体状态，了解组件所发出的请求经过的每一段链路的情况，提升系统架构的可见性。

（2）提高排除故障的效率

由于可观测系统提高了系统架构的可见性，因此研发人员可以清晰地了解发生故障时系统中其他组件的情况，以及发生故障的请求经过的每一段链路的情况。这不仅可以极大地提高研发人员排除故障的效率，还可以快速找到问题根因。

（3）提供更好的研发质量

可观测系统通过对应用全生命周期进行监控，实时记录每次生产版本变更前后的线上系统性能的情况，从而帮助研发人员更好地提升研发软件本身的质量。另外，通过对线上不同版本的服务进行对比分析可以提升服务质量。

本节深入分析了研发人员在可观测系统中的职责、研发人员关注的数据和系统对研发人员的价值。可观测系统不仅可以让包括研发、运维、测试在内的所有人员都能使用同一套系统，实时了解系统运行的情况，还可以让所有人员能够高效协作解决线上问题，最大限度地减少信息屏障和沟通不畅引起的问题。