1.引言
全栈可观测是一种更全面、更综合和更深入的观测能力，能协助全面了解和监测系统的各个层面和组件，它不仅仅是一个技术上的概念，更多地是技术与业务的结合。在“以业务为导向”的大前提下，全栈可观测正在成为趋势。
本文分享了阿里云可观测平台服务作为全球分布的超大业务系统，同时也作为服务全球企业用户的可观测平台提供方，在故障洞察提效中遇到的业务挑战，以及 6 个关键技术点和 2 个应用案例。
2.背景
全栈可观测是一个技术和业务相结合的领域，单从技术维度理解，可观测包含了基础设施、应用服务、客户端等等，而是更广义的维度则关注这项技术如何支撑企业的业务，提供跨越各个层面的数据收集、分析和可视化，帮助企业更好地理解和管理其系统和应用。从技术开源到各类头部厂商的产品，再到国内外多个业务组织的落地，都可以看出全栈可观测已经成为一种技术趋势。
Gartner 报告显示，落地可观测性具有相当高的战略价值
这一观点也在 Gartner 的报告中得到印证，根据 Gartner 的预测，到 2026 年，成功应用可观测性的 70% 组织将能够实现更短的决策响应时间，从而为目标业务或 IT 流程带来竞争优势，这说明可观测技术已经突破了技术层面，进入业务层面。
所以从业务视角来看，业务的变化（规模，复杂性，稳定性要求）必然驱动企业对可观测技术提出更高的要求。阿里云可观测平台服务作为一个全球分布的超大业务系统，同时也作为服务全球企业用户的可观测平台提供方，由于其支撑的业务架构的不断变化，驱动了可观测技术栈的不断演进。
今天我将结合阿里云的可观测业务挑战，重点从几项关键性技术和场景，与大家交流我对可观测技术的思考。
3.业务如何推动阿里云观测技术演进？
阿里云可观测性技术发展时间线
2012 年鹰眼系统打通应用和中间件：阿里云可观测性技术起点可以追溯到 11 年前，当时淘宝开始逐步实施微服务架构，这导致了大量服务之间相互调用非常复杂。因此，在这个时期我们构建了鹰眼监控系统（EagleEye），来解决不同业务之间的调用问题。可以说，正是淘宝业务的快速发展和微服务架构的演进，才促成了这一技术的产生，也为后期的可观测体系打下了基础。
2013-2015 年引入指标和日志：这个阶段，从社区的角度来看，容器技术和开源项目开始出现。同时，类似于 Service Mesh 这样的项目也应运而生。由于底层基础设施的改变，即容器化的普及，监控领域出现了新的需求和要求。我们的监控技术方向也逐步从打通应用和中间件之间的调用链，演进到引入观测指标和日志等。
2017 年 ARMS 云服务：“可观测性”这个词正式出现并明确了其定义，即关注的数据维度，如指标等。阿里云随即基于原有的鹰眼监控系统，推出了产品化的服务 ARMS。
2022 年全栈可观测套件：在上云容器化、平台化的前提下，开源社区的发展带来了相对规范的可观测技术栈，所以阿里云在 2022 年发布了全栈的可观测相关技术，基于开源的规范实现相关的云服务。
从阿里近 10 年的监控技术发展可以看出，技术并不是自发演进的，更多是由于业务架构和基础设施架构的变化推动了可观测性技术的架构改变。
4.阿里云的可观测遇到了哪些挑战？
4.1作为平台方：服务全球企业用户
4.2作为业务系统：全球分布
4.2.1确保较高的业务能见度
我们经常面临用户无法找到其观测数据的问题。这是一个常见的挑战，需要我们思考，从数据采集到存储和消费如何确保高度的业务可见性。
4.2.2如何确保SLA达标
上述的问题只是一个表面现象，我们需要深入了解问题的根本原因。可观测性数据链路非常长，涵盖了从数据采集、端侧处理、服务端处理、存储到查询等全链路的业务系统。因此，我们需要快速诊断故障，确定是哪个环节出现了问题，或者是否是由于用户配置问题导致的等等。我们需要在最短的时间内诊断用户数据链路故障并可视化故障，将平均定位时间从 10 分钟降低到 5 分钟或更低。我将在后面分享具体的实践方式。
4.2.3如何支撑业务决策
同时，我们自身也需要做出许多决策，无论是关于服务和产品的模式、架构，还是产品运营的形态等等。我们要知道用户需要哪些可观测生态能力，并建立观测数据模型进行精确评估。
5.有哪些关键性技术需要突破？
5.1我们需要什么样的观测数据？
对于关注可观测性技术的同学来说，这个图应该很熟悉。开源社区对可观测性的定义是指标、日志、调用链和 Profiles，这四类数据实际上存在很多交叉，而不是完全分离的。这个交叉意味着这几种数据本质上是相似的，它们都用于反映业务运行的技术状态和业务数据状态，只是捕获数据的渠道和形式不同。如果要比较这几种数据，可以从以下维度考虑。
指标(Metrics）：
相对而言，指标数据是成本最低的，因为它们是提前计算好的数据。通常情况下，我们可以通过分析日志等方式来计算得到这些数据。例如，每天的请求数（QPS）等指标可以直接反映我们想要了解的数据。当然，如果要从日志中计算这些指标，就需要大量的数据才能得出结果。可以说指标数据是相对有效和直接的数据形式，通常以数字形式呈现。但对于开发者来说，如果可观测平台的建设者和开发者是分离的，开发者可能不太愿意进行较多的改动，因为这些改动会有一定代码侵入性。
日志（Logging)：
日志数据的有效信息密度相对较低，因此完全存储和检索它的成本较高。不过，在不同的业务系统中，日志通常被细分为访问日志、业务日志、错误日志等等。因此，使用日志来快速定位系统故障是最方便的方法，打印一条日志或编写一行代码是相对容易的操作。对于事件类的日志通常作为审计的原始数据，低成本存储也是大多数业务希望的。
调用链(Tracing）：
调用链是在日志基础上增加关联性的一种衍生数据。它将一次请求的前后调用关联起来，从而产生增强效果。调用链具有较强的数据关联性，但也伴随较高的成本。因此，我们需要考虑采样问题。
调用链的好处是能够快速定位复杂系统故障，特别是涉及多个服务的情况。通过调用链，我们可以准确定位 API 请求故障的具体位置。相比之下，仅从日志出发可能需要进行回溯并对业务有一定了解。而指标数据可能只是一种侧面的统计模式。在这些不同数据类型之间有很多转化点，我们将在后面具体介绍。
Profiles：
这是近年来受到更多关注的数据类型。它深入到了我们应用程序的细节，当然不同的开发语言可能有所不同。一般情况下，我们会在需要提升性能或者发现内存泄漏、CPU 占用过高等疑难杂症时使用这种观测数据模式。它能够快速定位到代码中出现问题的具体位置。
在全栈可观测体系中，以上几种数据类型通常会被统一使用。同时，考虑到成本问题，我们会进行转换和选择性存储，最终综合利用这些数据。如果只能选择一种数据类型的话，指标是最直接的一种观测数据。
5.2关键点 1：多种部署形态下的数据采集架构
在现代的部署环境中，特别是云上的环境，我们可以将其分为容器集群、ECS 主机和云服务。在考虑全栈时，我们的业务系统可能是自研的，以容器的形式运行在云上或自建机房中；也可能是相对传统的结构，在虚拟机上运行。云服务中间件也是大多数企业的选择。因此，在建立全栈的数据采集时，我们必须考虑这些不同的维度。
再说说探针核心要考虑的维度——
5.2.1不丢数据
这是最基础的要求，但实际上也是最难的要求。有经验的探针开发人员都知道，在面对超大规模集群时，日志采集、应用 Tracing 数据采集和指标采集，数据量都是海量的。因此，如何确保不丢失数据是探针开发中必要的设计因素。
根据部署形态或架构形态，探针可以分为运行在集群、节点、应用这样三个维度。
应用维度的探针，它采集的数据主要以调用链为主，因为只有调用链才必须侵入应用。而无侵入的调用链形态，目前还在发展过程中，不同的开发语言还没有太好的方法能够实现。因此，在 APM 形态下，都以应用探针为主。
节点维度的探针，它面对的是在同一内核的业务，即容器化部署后，同一个节点上会有多个容器，可能几十到几百个不等。同理，在 ECS 上也是节点级别的，它可以借助 eBPF 相关技术实现无侵入采集指标、业务日志等等。无侵入 Tracing 采集也是在节点探针这个维度考量。
集群维度的探针，它的核心是作为数据中转，将前置数据采集的逻辑在单集群侧先进行计算，比如日志本身的转化、Relable 等等。同时，也需要实现服务发现去采集一些指标的数据，比如常见的业务暴露指标，错误数、请求数等等。
通过多级的 Agent 模式，帮助我们在大集群中分类采集不同的数据，然后上传到服务端。上传数据时会采用分包原则，确保每一个数据包都上传到网关。网关仅接受数据压缩包立即转到背后的消息中间件，不拆包。继而可以保障高性能接受数据包，确保在 Agent 侧不阻塞。
5.2.2实时采集
另一个维度是实时采集，即需要降低延迟，避免数据在几分钟甚至更长时间后才被存储到服务端并供用户查询到。因此，我们需要尽快采集数据，让 Agnet 在处理大量数据时的并行能力需要足够强大。
所以集群探针的多副本采集是关键技术之一。当我们面对多个采集 Target 采集目标时，需要创建多个采集工作副本，自动均衡采集不同 Target 的指标，并在短时间内将其发送到后端。Tracing 等应用端数据天然分散式采集。
5.2.3就近处理
当考虑全链路的实时性时，除了采集外，存储处理的逻辑也是必须要考虑的。这里引出了另外一个重要问题是就近处理，其目的是为了降低成本。因为一旦将数据发送到服务端，就会带来计算和存储的成本。面向日志和特定 Tracing 数据，我们可以降采样或做转化，通过在端侧提前处理，最终产出的指标数据成本会相对较低。
5.2.4智能关联/打标签
在进行全栈数据查询时，智能关联和打标签是关键。在采集不同的应用时，它可能会有多种标签，例如某个 APP ID、访问域名。通过对原始数据进行处理，我们可以统一打上标签，并在查询时将它们关联起来。
5.2.5无侵入采集
目前在可观测领域，无侵入的采集方式被视为关键技术，因为它能够降低对业务代码的侵入，使技术栈更容易落地。下面我将重点讲解。
5.3关键点 2：基于 eBPF 的无侵入数据采集能力
eBPF 作为一种无侵入的数据采集能力，被认为是非常重要的技术手段。无侵入的采集方式能够减少对研发的影响，使得技术栈的部署更加顺利。目前，这种采集方式在社区和实践中得到广泛应用。
无侵入采集方式不会对业务代码产生干扰，它是在运行的内核中工作，例如 Linux 内核可以采集 IO 数据，其中包括网络 IO、文本文件 IO 等。目前最常用的是网络 IO，也就是请求的黄金三指标数据。通过从内核直接捕获这些数据，则能快速计算出黄金三指标。我们可以从图中简单了解它的工作模式。
我们通过节点探针向内核下发相关的 eBPF 脚本，内核会自动加载并捕获当前节点下的所有网络调用。然后，它会自动解码应用的协议，并计算出黄金三指标。这种模式适用于不同的通信协议，可以计算出具体的黄金三指标。这些指标以及一些分段的 Tracing 数据会被发送到集群探针侧进行处理，或者直接存储。
在这个过程中，我们可以从这个大图中看到一个完整的业务系统可能使用不同的开发语言，如 Node.js、Java、PHP 等。对于 Java 来说，由于其侵入性（侵入 Jvm 运行时）探针的发展相对成熟，它的探针功能更丰富。而对于其他语言，业界更多地使用无侵入的 eBPF 技术来分析指标和调用链，建立整个链路。因此，我们可以从不同的技术栈采集相关的指标数据，从而得到整体架构。
网络通信版本的全栈可观测架构图
这个图展示了通信、进程和协议等更详细的信息，还可以标识每个请求之间的关联 Span ID 等。这些信息分析后可以方便我们进行整体的可观测性。
然而，这些技术也面临一些挑战，比如会占用较高的资源。由于需要分析网络协议，解码通信包，就会消耗大量的 CPU 资源，相比于直接注入 Java 探针或者业务方编写代码来体现指标，无侵入方式的资源占用更高。如果我们要选择的话，更好的方式是让业务开发者以一种标准的方式生成指标，以提升业务自身的可观测性。
另外一个挑战是智能识别通信链路中的每个节点。我们可以通过域名、IP 地址等维度来识别通信的目标，例如 RDS 是否基于某个云服务或自建服务，需要进行识别并进行关联。
所以，这个技术的门槛相对较高，但好在开源社区和阿里云上都有相关的技术和产品可供使用。
5.4关键点 3：存储成本控制的技术要点
在讨论采集和存储的过程中，我想重点谈一谈降低成本的问题。因为可观测的核心是需要处理大量的数据，而数据处理会产生成本，这也是很多团队决策更快引入可观测性的一个重要因素。在这个过程中，有很多技术性的因素需要考虑，我举几个例子来说明。
5.4.1Metrics 成本陡增的真相
问题背景：
举一个例子来说明，在指标处理这个方面，假设我们通过一种旁路的方式捕获到了一个指标，比如请求的状态。这种指标很简单，它可以用来标记每天的请求数量。然而，如果我们在设计中没有很好地把握，比如在标签中引入了一个变化量很大的变量，例如 User ID，而业务系统有 1000 万活跃用户，那么就会同时产生 1000 万条时间线。这样的数据量相对其价值通常是不成正比的。这是我们在为大多数用户提供服务的过程中经常遇到的成本爆炸场景之一。
解决思路：
那么，如何解决这个问题呢？其实解决思路还是相对简单明了的。首先，我们在生成指标时要避免出现这样的模式。如果我们不需要如此详细的数据（一般情况下是不需要的），就不要设计这样的指标标签。这是最根本的解决思路。然而，作为平台方，很难要求所有用户都遵循这个规则。因此，我们需要考虑从服务端提供一些机制来处理这个问题。
具体方案：
第一个是 Prometheus 社区的方案，即在采集数据时对标签进行重写，将变化较大的数字转换为通配符，从而降低整个指标。然而，这种方法依赖于用户具备相关经验，并能配置相关策略。
那么，是否有更简单、更智能的方式？我们在服务端采用了一种自动处理的方式。当数据流进入处理流程后，系统会自动判断指标是否开始发散。如果发现这样的事件发生，服务会触发生成相应的规则，并将规则注入到处理的链路过程中。这样，1000 万条数据就自动转化，最终存储中可能只有一条数据。这种自动转化的逻辑依赖于发散数据。整个过程背后需要有经验的积累，才能生成相应规则来自动处理这样的事件。
另外，一些厂商还会使用存储降成本的逻辑，即数据是否可以取消更多索引，但这会增加成本并可能对存储的非通用性要求更多。
我个人认为，最简单的方式还是在产生指标时就考虑这个问题。将指标的合理的设计纳入到技术设计中。
5.4.2如何有效降低 Traces 成本
问题背景：
以图为例，我们通常认为 90% 以上的测试数据和日志一样，大多数情况下是没有用的。除非出现问题或者想了解某个调用链的背后调用，否则一般不会去查看它的调用链是否正确。因此，存储全量数据后再使用全量数据，则会带来很高的成本。但如果只是简单按比例采样，数据失真也是非常可怕的，可能会错过一些错误，也失去了观测的意义。有什么方法可以解决这个问题呢？
解决思路：
在实践中，我们尝试了几种方法，这里分享一种按业务语义来处理数据的方式。
我们分析数据时，通常用户在调用产生后的短期内（例如 30 分钟）会去查询调用链的状态。随着时间的推移，查询比例通常会非常低，这是基于业务分析的结果。因此，我们提出了热数据和冷数据的分类方式。
热数据用于实时查询，冷数据则用于排查问题或进行最终统计。在热数据转化为冷数据的过程中，我们需要存储有错误的调用链，而其他数据则按一定比例进行采样存储。通过这样的存储模式，我们不能用冷数据产生的统计指标来评估业务的性能，它只是作为从调用链维度进行分析的参考数据。因此，我们非常关注错误的，或较慢的调用链的数据，必须将其保存下来。总体而言，这种处理思路降低了冷数据存储的成本，同时也降低了最终用户查询的成本。
5.5关键点 4：预先提取关键数据
5.5.1Trace2Metric
以调用链为例，通常我们关注的场景是单条调用链的上下游追溯。但更多的情况是基于 Trace 数据进行统计分析，统计业务的请求量、错误和耗时等黄金指标。
在构建追踪系统时，我们将其分为两类查询：一类是查询调用链，另一类是基于调用链生成的统计数据，我们称之为指标。对于这些指标的计算，我们可以将其前移以降低成本。具体而言，我们引入了 Trace2Metric 的模式，将追踪数据进入处理链路后先进行处理，生成统计指标，比如某两个服务之间调用的数量、错误数和耗时等指标，然后将其存储到指标存储系统中。至于其他原始 Trace 数据，可以通过之前提到的冷热数据方式进行处理，或以低成本的方式全量存储，例如去掉所有索引，只存储原始文本数据。
通过这样的方式分流数据，我们在用户端通过可视化系统进行查询时，更频繁地查询的是指标，而较低频的查询则是原始 Trace 数据。因此，在整体上降低了低频查询的存储成本，而高频查询的指标是聚合的，所以指标量也较小。通过这样的处理模式，我们可以逐步演进数据处理链路。
5.5.2Log2Metric
在处理日志的指标时，思考模式与 Tracing 类似。实际上，日志更容易产生指标，特别是访问日志，如网关日志或业务的访问日志。这类日志通常需要统计整体业务或基于业务维度的数据，而单点查询很少。例如，统计哪些用户访问了哪个业务系统。因此，在采集日志数据后，我们可以直接进行产生指标的处理。
在开源社区中已有相关的方案，如 Vector 模式，它对日志进行前置处理并生成指标。后续的存储方式与前面的 Trace 类似。
综上所述，我们主要从以上几个维度考虑来降低存储成本。
5.6关键点 5：观测数据全局聚合查询
5.6.1应用场景
数据的使用取决于存储形态。以指标为例，业务指标的数据可能存在几种场景。
跨账号的数据聚合查询：在云上可能存在不同账号的数据，每个账号对应不同的业务团队。但是在整体视角下进行可观测时，需要将相关数据聚合在一起进行可视化、告警等操作。
跨 Region 的数据聚合查询：从技术角度来看，可能存在跨地域、甚至跨国的数据查询需求。例如，北京可能有相关业务，杭州也有相关业务，北美也有相关业务。在观测整个业务系统时，需要从这些不同地域甚至跨国 Region 查询相应的数据。
跨实例(数据域)的数据聚合查询：这个场景颗粒度更小，是数据的多租存储，即分不同的实例存储。此时最基础的粒度则是跨实例（数据域）。比如，某个实例存储后端服务的观测数据，另一个实例存储前端和 APP 的观测数据，还有一个实例存储云服务的观测数据。在做全栈观测时，需要将不同场景的数据进行聚合查询。
5.6.2解决思路
为了实现这一目标，我们需要选择合适的技术来进行聚合查询。那么聚合查询是这么做的？
这里得益于开源规范，在指标处理的链路中，以 Prometheus 规范为主。该规范定义了丰富的算子和查询语法。所有 PromQL 的查询语法进入到聚合查询实例后，就会拆解里面的每个算子，并将其发送到目标数据存储实例进行计算。然后将这些数据重新流回聚合实例进行聚合，并响应给用户。对于用户来说，这种计算和汇总的逻辑是透明的，因为他们只需要提供一个查询语法即可。同时，通过指标加标签的机制，我们可以很好地分辨出数据的共同标签、差异化标签，从而了解这些数据的来源。这种模式能够帮助我们构建不同场景的可观测性视图。
5.7关键点 6：构建无处不在的可观测基础设施
有了采集、存储、查询等基础设施后，构建全栈的可观测能力就必然需要面向场景。
在场景方面，通常可以分为基础设施的观测、应用的实时观测、前端的观测、APP 的观测以及主动的云拨测等。这些观测点都能从可观测平台进行分类。
在具体的业务场景中，则不需要考虑这些，直接根据业务形态选择适合的观测方式。在提供这些能力时，我们要考虑开源的兼容性。因此，以开箱即用的方式提供开源和云服务的观测方案是非常重要的。开箱即用意味着每个场景的告警、大盘数据源、数据采集和处理规则等都以独立的聚合方案的形式直接可用。这对于构建可观测平台是一个重要参考。我们提供给开发者和业务团队的，不能仅仅是技术的基础设施，而是应该是基于开源视角、业务视角和公共服务视角的最佳实践，以包装好的方式提供给平台用户使用。同时这种包装需要是标准化，可扩展的，我们的研发甚至是用户可以根据需求随时定义新的插件，利用平台已有的能力，形成可复用的解决方案。
6.可观测平台的实践和落地效果
6.1自身实践：阿里云构建全域 SLA 可观测
作为一个全球分布的业务系统，阿里云云原生可观测团队需要关注自身的观测和降低用户故障发现的时间。为此，我们需要构建一个全面的可观测团队视图。涵盖几个关键维度的数据：SLA 可用性、成本和稳定性、用户运营（用户规模、新增用户数量等）。
从这些需求中可以看到，我们的观测需求是广义上的全栈可观测。从 SRE、稳定性、业务运营等多个维度建立观测视图。
再细分 SLA 的可观测性需求，它涉及到了全球不同地域的数据采集、存储和使用侧的聚合查询。再根据不同的业务形态选择不同的观测手段。在数据层面，我们统一进行用户、地域和业务域等维度打标和数据查询。
对于我们的业务分布，一个是控制面，一个是数据面，我们需要针对不同的维度进行面向用户的聚合。在控制面中，我们关注用户的操作，例如开通哪些实例等。在数据链路中，我们关注每个用户在特定环境中的数据采集、存储和查询情况。应用各种观测技术手段，我们可以从下往上进行聚合，最终形成完整的观测视图。我们可以通过两个截图来说明。
第一个截图展示了 Agent 采集侧的 SLA 观测大盘，支持从用户维度、地域维度和用户环境维度观测数据采集状态，发现故障域，以及通过指标、日志等手段直接定位采集细节状态，达到洞察故障的效果。
第二个截图展示了存储侧的聚合数据，可以让我们直接看到 SLA 的情况。支持从用户维度、地域维度和用户实例维度观测数据写入 SLA，先于用户发现写入环节故障。
即使我们支持用户工单的同学具有不同的技术背景，也可以通过全栈观测大盘快速发现用户问题，解决效率大大提高。我们内部数据统计，通过建立多维度的观测大盘，整体故障洞察效率提升了 50%。
6.2用户实践：传音的全栈可观测实践
作为“非洲手机之王”，传音从事以手机为核心的智能终端的设计、研发、生产、销售和品牌运营，是新兴市场消费者喜爱的智能终端产品和移动互联服务提供商。据 IDC 报告显示 2021 年占据非洲智能手机出货量的 47.9%。传音移动互联广告平台是传音控股的重要业务之一，是非洲最为主流的营销平台之一。
客户痛点：
在技术架构方面，传音控股采用 Spring Cloud 进行全面微服务化， 应用运行在阿里云容器服务 ACK 之上，并分布在欧洲、亚洲等多个地区，真正实现了多地区服务体系。对于该体系而言，要构建完整的可观测体系，挑战非常大。
需求概述：
- 可观测性应覆盖从研发到生产的全周期。
- 同时需要监控全球多个容器集群，云服务基础设施。
- 打通应用和基础设施观测，统一观测调用链和性能、可用性指标。
方案概述：
- 自建流水线数据采集系统，通过 Grafana 展示应用构建数据
- 采用 ARMS Prometheus 产品监控容器集群和应用性能及调用链，集成 Grafana 完成多集群统一监控
- SLS 产品完成业务日志、应用日志、容器日志的采集/存储/展示，并通过查询语句生成指标，在 Grafana 中展示
- 统一采集云服务观测数据，结合基础应用数据统一观测。
落地成效：
传音在建立全新的可观测技术能力后，不仅提升了问题诊断效率，还提升了用户体验。在此基础上，结合其他云原生新技术方案，业务上线效率提高了 60%，对于高效业务创新起到了至关重要的作用。
7.总结与展望
开源技术和开源社区的发展带来了标准化，覆盖了全栈技术和全栈业务方向的数据收集、存储和可视化等方面。而可观测性的厂商推出了全栈可观测的综合方案，引领用户实践，使得全栈状态更易实现。在此基础上，全栈可观测的实践案例得以在更多业务组织中落地。
当然应用可观测性技术带来了业务能见度、决策支持、成本优化和组织合作改进等收益，但同时，大多数业务组织也面临着技术复杂性、成本控制、组织文化变革、数据管理等方面的挑战。
我们可以看到，越来越多的企业正在克服这些难题，让可观测技术突破技术层面，进入业务层面，并得到更加广泛的落地。可观测，无处不在！
