一分钟精髓速览
全栈可观测是一种更全面、更综合和更深刻的观测能力，能帮助全面理解和监测零碎的各个层面和组件，它不仅仅是一个技术上的概念，更多地是技术与业务的联合。在“以业务为导向”的大前提下，全栈可观测正在成为趋势。
本文分享了阿里云可观测平台服务作为寰球散布的超大业务零碎，同时也作为服务寰球企业用户的可观测平台提供方，在故障洞察提效中遇到的业务挑战，以及 6 个关键技术点和 2 个利用案例。
背景
全栈可观测是一个技术和业务相结合的畛域，单从技术维度了解，可观测蕴含了基础设施、应用服务、客户端等等，而是更狭义的维度则关注这项技术如何撑持企业的业务，提供逾越各个层面的数据收集、剖析和可视化，帮忙企业更好地了解和治理其零碎和利用。从技术开源到各类头部厂商的产品，再到国内外多个业务组织的落地，都能够看出全栈可观测曾经成为一种技术趋势。
$$
Gartner 报告显示，落地可观测性具备相当高的策略价值
$$
这一观点也在 Gartner 的报告中失去印证，依据 Gartner 的预测，到 2026 年，胜利利用可观测性的 70% 组织将可能实现更短的决策响应工夫，从而为指标业务或 IT 流程带来竞争劣势，这阐明可观测技术曾经冲破了技术层面，进入业务层面。
所以从业务视角来看，业务的变动（规模，复杂性，稳定性要求）必然驱动企业对可观测技术提出更高的要求。阿里云可观测平台服务作为一个寰球散布的超大业务零碎，同时也作为服务寰球企业用户的可观测平台提供方，因为其撑持的业务架构的一直变动，驱动了可观测技术栈的一直演进。
明天我将联合阿里云的可观测业务挑战，重点从几项关键性技术和场景，与大家交换我对可观测技术的思考。
01 业务如何推动阿里云观测技术演进？
$$
阿里云可观测性技术倒退工夫线
$$
2012 年鹰眼零碎买通利用和中间件：阿里云可观测性技术终点能够追溯到 11 年前，过后淘宝开始逐渐施行微服务架构，这导致了大量服务之间互相调用非常复杂。因而，在这个期间咱们构建了鹰眼监控零碎（EagleEye），来解决不同业务之间的调用问题。能够说，正是淘宝业务的疾速倒退和微服务架构的演进，才促成了这一技术的产生，也为前期的可观测体系打下了根底。
2013-2015 年引入指标和日志：这个阶段，从社区的角度来看，容器技术和开源我的项目开始呈现。同时，相似于 Service Mesh 这样的我的项目也应运而生。因为底层基础设施的扭转，即容器化的遍及，监控畛域呈现了新的需要和要求。咱们的监控技术方向也逐渐从买通利用和中间件之间的调用链，演进到引入观测指标和日志等。
2017 年 ARMS 云服务：“可观测性”这个词正式呈现并明确了其定义，即关注的数据维度，如指标等。阿里云随即基于原有的鹰眼监控零碎，推出了产品化的服务 ARMS。
2022 年全栈可观测套件：在上云容器化、平台化的前提下，开源社区的倒退带来了绝对标准的可观测技术栈，所以阿里云在 2022 年公布了全栈的可观测相干技术，基于开源的标准实现相干的云服务。
从阿里近 10 年的监控技术倒退能够看出，技术并不是自发演进的，更多是因为业务架构和基础设施架构的变动推动了可观测性技术的架构扭转。
02 阿里云的可观测遇到了哪些挑战？
2.1 作为平台方：服务寰球企业用户
2.2 作为业务零碎：寰球散布
2.2.1 确保较高的业务能见度
咱们常常面临用户无奈找到其观测数据的问题。这是一个常见的挑战，须要咱们思考，从数据采集到存储和生产如何确保高度的业务可见性。
2.2.2 如何确保 SLA 达标
上述的问题只是一个表面现象，咱们须要深刻理解问题的根本原因。可观测性数据链路十分长，涵盖了从数据采集、端侧解决、服务端解决、存储到查问等全链路的业务零碎。因而，咱们须要疾速诊断故障，确定是哪个环节呈现了问题，或者是否是因为用户配置问题导致的等等。咱们须要在最短的工夫内诊断用户数据链路故障并可视化故障，将均匀定位工夫从 10 分钟升高到 5 分钟或更低。我将在前面分享具体的实际形式。
2.2.3 如何撑持业务决策
同时，咱们本身也须要做出许多决策，无论是对于服务和产品的模式、架构，还是产品经营的状态等等。咱们要晓得用户须要哪些可观测生态能力，并建设观测数据模型进行准确评估。
03 有哪些关键性技术须要冲破？
3.1 咱们须要什么样的观测数据？
对于关注可观测性技术的同学来说，这个图应该很相熟。开源社区对可观测性的定义是指标、日志、调用链和 Profiles，这四类数据实际上存在很多穿插，而不是齐全拆散的。这个穿插意味着这几种数据实质上是类似的，它们都用于反映业务运行的技术状态和业务数据状态，只是捕捉数据的渠道和模式不同。如果要比拟这几种数据，能够从以下维度思考。
指标(Metrics）：
相对而言，指标数据是老本最低的，因为它们是提前计算好的数据。通常状况下，咱们能够通过剖析日志等形式来计算失去这些数据。例如，每天的申请数（QPS）等指标能够间接反映咱们想要理解的数据。当然，如果要从日志中计算这些指标，就须要大量的数据能力得出后果。能够说指标数据是绝对无效和间接的数据模式，通常以数字模式出现。但对于开发者来说，如果可观测平台的建设者和开发者是拆散的，开发者可能不太违心进行较多的改变，因为这些改变会有肯定代码侵入性。
日志（Logging)：
日志数据的无效信息密度绝对较低，因而齐全存储和检索它的老本较高。不过，在不同的业务零碎中，日志通常被细分为拜访日志、业务日志、谬误日志等等。因而，应用日志来疾速定位系统故障是最不便的办法，打印一条日志或编写一行代码是绝对容易的操作。对于事件类的日志通常作为审计的原始数据，低成本存储也是大多数业务心愿的。
调用链(Tracing）：
调用链是在日志根底上减少关联性的一种衍生数据。它将一次申请的前后调用关联起来，从而产生加强成果。调用链具备较强的数据关联性，但也随同较高的老本。因而，咱们须要思考采样问题。
调用链的益处是可能疾速定位简单系统故障，特地是波及多个服务的状况。通过调用链，咱们能够精确定位 API 申请故障的具体位置。相比之下，仅从日志登程可能须要进行回溯并对业务有肯定理解。而指标数据可能只是一种侧面的统计模式。在这些不同数据类型之间有很多转化点，咱们将在前面具体介绍。
Profiles：
这是近年来受到更多关注的数据类型。它深刻到了咱们应用程序的细节，当然不同的开发语言可能有所不同。个别状况下，咱们会在须要晋升性能或者发现内存透露、CPU 占用过低等疑难杂症时应用这种观测数据模式。它可能疾速定位到代码中呈现问题的具体位置。
在全栈可观测体系中，以上几种数据类型通常会被对立应用。同时，思考到老本问题，咱们会进行转换和选择性存储，最终综合利用这些数据。如果只能抉择一种数据类型的话，指标是最间接的一种观测数据。
3.2 关键点 1：多种部署状态下的数据采集架构
在古代的部署环境中，特地是云上的环境，咱们能够将其分为容器集群、ECS 主机和云服务。在思考全栈时，咱们的业务零碎可能是自研的，以容器的模式运行在云上或自建机房中；也可能是绝对传统的构造，在虚拟机上运行。云服务中间件也是大多数企业的抉择。因而，在建设全栈的数据采集时，咱们必须思考这些不同的维度。
再说说探针外围要思考的维度——
3.2.1 不丢数据
这是最根底的要求，但实际上也是最难的要求。有教训的探针开发人员都晓得，在面对超大规模集群时，日志采集、利用 Tracing 数据采集和指标采集，数据量都是海量的。因而，如何确保不失落数据是探针开发中必要的设计因素。
依据部署状态或架构状态，探针能够分为运行在集群、节点、利用这样三个维度。
利用维度的探针，它采集的数据次要以调用链为主，因为只有调用链才必须侵入利用。而无侵入的调用链状态，目前还在倒退过程中，不同的开发语言还没有太好的办法可能实现。因而，在 APM 状态下，都以利用探针为主。
节点维度的探针，它面对的是在同一内核的业务，即容器化部署后，同一个节点上会有多个容器，可能几十到几百个不等。同理，在 ECS 上也是节点级别的，它能够借助 eBPF 相干技术实现无侵入采集指标、业务日志等等。无侵入 Tracing 采集也是在节点探针这个维度考量。
集群维度的探针，它的外围是作为数据直达，将前置数据采集的逻辑在单集群侧先进行计算，比方日志自身的转化、Relable 等等。同时，也须要实现服务发现去采集一些指标的数据，比方常见的业务裸露指标，谬误数、申请数等等。
通过多级的 Agent 模式，帮忙咱们在大集群中分类采集不同的数据，而后上传到服务端。上传数据时会采纳分包准则，确保每一个数据包都上传到网关。网关仅承受数据压缩包立刻转到背地的消息中间件，不拆包。继而能够保障高性能承受数据包，确保在 Agent 侧不阻塞。
3.2.2 实时采集
另一个维度是实时采集，即须要升高提早，防止数据在几分钟甚至更长时间后才被存储到服务端并供用户查问到。因而，咱们须要尽快采集数据，让 Agnet 在解决大量数据时的并行能力须要足够弱小。
所以集群探针的多正本采集是关键技术之一。当咱们面对多个采集 Target 采集指标时，须要创立多个采集工作正本，主动平衡采集不同 Target 的指标，并在短时间内将其发送到后端。Tracing 等利用端数据人造分散式采集。
3.2.3 就近解决
当思考全链路的实时性时，除了采集外，存储解决的逻辑也是必须要思考的。这里引出了另外一个重要问题是就近解决，其目标是为了降低成本。因为一旦将数据发送到服务端，就会带来计算和存储的老本。面向日志和特定 Tracing 数据，咱们能够降采样或做转化，通过在端侧提前解决，最终产出的指标数据老本会绝对较低。
3.2.4 智能关联 / 打标签
在进行全栈数据查问时，智能关联和打标签是要害。在采集不同的利用时，它可能会有多种标签，例如某个 APP ID、拜访域名。通过对原始数据进行解决，咱们能够对立打上标签，并在查问时将它们关联起来。
3.2.5 无侵入采集
目前在可观测畛域，无侵入的采集形式被视为关键技术，因为它可能升高对业务代码的侵入，使技术栈更容易落地。上面我将重点解说。
3.3 关键点 2：基于 eBPF 的无侵入数据采集能力
eBPF 作为一种无侵入的数据采集能力，被认为是十分重要的技术手段。无侵入的采集形式可能缩小对研发的影响，使得技术栈的部署更加顺利。目前，这种采集形式在社区和实际中失去广泛应用。
无侵入采集形式不会对业务代码产生烦扰，它是在运行的内核中工作，例如 Linux 内核能够采集 IO 数据，其中包含网络 IO、文本文件 IO 等。目前最罕用的是网络 IO，也就是申请的黄金三指标数据。通过从内核间接捕捉这些数据，则能疾速计算出黄金三指标。咱们能够从图中简略理解它的工作模式。
咱们通过节点探针向内核下发相干的 eBPF 脚本，内核会主动加载并捕捉以后节点下的所有网络调用。而后，它会主动解码利用的协定，并计算出黄金三指标。这种模式实用于不同的通信协议，能够计算出具体的黄金三指标。这些指标以及一些分段的 Tracing 数据会被发送到集群探针侧进行解决，或者间接存储。
在这个过程中，咱们能够从这个大图中看到一个残缺的业务零碎可能应用不同的开发语言，如 Node.js、Java、PHP 等。对于 Java 来说，因为其侵入性（侵入 Jvm 运行时）探针的倒退绝对成熟，它的探针性能更丰盛。而对于其余语言，业界更多地应用无侵入的 eBPF 技术来剖析指标和调用链，建设整个链路。因而，咱们能够从不同的技术栈采集相干的指标数据，从而失去整体架构。
$$
网络通信版本的全栈可观测架构图
$$
这个图展现了通信、过程和协定等更具体的信息，还能够标识每个申请之间的关联 Span ID 等。这些信息剖析后能够不便咱们进行整体的可观测性。
然而，这些技术也面临一些挑战，比方会占用较高的资源。因为须要剖析网络协议，解码通信包，就会耗费大量的 CPU 资源，相比于间接注入 Java 探针或者业务方编写代码来体现指标，无侵入形式的资源占用更高。如果咱们要抉择的话，更好的形式是让业务开发者以一种规范的形式生成指标，以晋升业务本身的可观测性。
另外一个挑战是智能辨认通信链路中的每个节点。咱们能够通过域名、IP 地址等维度来辨认通信的指标，例如 RDS 是否基于某个云服务或自建服务，须要进行辨认并进行关联。
所以，这个技术的门槛绝对较高，但好在开源社区和阿里云上都有相干的技术和产品可供使用。
3.4 关键点 3：存储老本管制的技术要点
在探讨采集和存储的过程中，我想重点谈一谈降低成本的问题。因为可观测的外围是须要解决大量的数据，而数据处理会产生老本，这也是很多团队决策更快引入可观测性的一个重要因素。在这个过程中，有很多技术性的因素须要思考，我举几个例子来阐明。
3.4.1 Metrics 老本陡增的假相
问题背景：
举一个例子来阐明，在指标解决这个方面，假如咱们通过一种旁路的形式捕捉到了一个指标，比方申请的状态。这种指标很简略，它能够用来标记每天的申请数量。然而，如果咱们在设计中没有很好地把握，比方在标签中引入了一个变动量很大的变量，例如 User ID，而业务零碎有 1000 万沉闷用户，那么就会同时产生 1000 万条工夫线。这样的数据量绝对其价值通常是不成正比的。这是咱们在为大多数用户提供服务的过程中常常遇到的老本爆炸场景之一。
解决思路：
那么，如何解决这个问题呢？其实解决思路还是绝对简单明了的。首先，咱们在生成指标时要避免出现这样的模式。如果咱们不须要如此具体的数据（个别状况下是不须要的），就不要设计这样的指标标签。这是最基本的解决思路。然而，作为平台方，很难要求所有用户都遵循这个规定。因而，咱们须要思考从服务端提供一些机制来解决这个问题。
具体计划：
第一个是 Prometheus 社区的计划，即在采集数据时对标签进行重写，将变动较大的数字转换为通配符，从而升高整个指标。然而，这种办法依赖于用户具备相干教训，并能配置相干策略。
那么，是否有更简略、更智能的形式？咱们在服务端采纳了一种主动解决的形式。当数据流进入解决流程后，零碎会主动判断指标是否开始发散。如果发现这样的事件产生，服务会触发生成相应的规定，并将规定注入到解决的链路过程中。这样，1000 万条数据就主动转化，最终存储中可能只有一条数据。这种主动转化的逻辑依赖于发散数据。整个过程背地须要有教训的积攒，能力生成相应规定来主动解决这样的事件。
另外，一些厂商还会应用存储降老本的逻辑，即数据是否能够勾销更多索引，但这会减少老本并可能对存储的非通用性要求更多。
我集体认为，最简略的形式还是在产生指标时就思考这个问题。将指标的正当的设计纳入到技术设计中。
3.4.2 如何无效升高 Traces 老本
问题背景：
以图为例，咱们通常认为 90% 以上的测试数据和日志一样，大多数状况下是没有用的。除非呈现问题或者想理解某个调用链的背地调用，否则个别不会去查看它的调用链是否正确。因而，存储全量数据后再应用全量数据，则会带来很高的老本。但如果只是简略按比例采样，数据失真也是十分可怕的，可能会错过一些谬误，也失去了观测的意义。有什么办法能够解决这个问题呢？
解决思路：
在实践中，咱们尝试了几种办法，这里分享一种按业务语义来解决数据的形式。
咱们剖析数据时，通常用户在调用产生后的短期内（例如 30 分钟）会去查问调用链的状态。随着工夫的推移，查问比例通常会非常低，这是基于业务剖析的后果。因而，咱们提出了热数据和冷数据的分类形式。
热数据用于实时查问，冷数据则用于排查问题或进行最终统计。在热数据转化为冷数据的过程中，咱们须要存储有谬误的调用链，而其余数据则按肯定比例进行采样存储。通过这样的存储模式，咱们不能用冷数据产生的统计指标来评估业务的性能，它只是作为从调用链维度进行剖析的参考数据。因而，咱们十分关注谬误的，或较慢的调用链的数据，必须将其保留下来。总体而言，这种解决思路升高了冷数据存储的老本，同时也升高了最终用户查问的老本。
3.5 关键点 4：事后提取要害数据
3.5.1 Trace2Metric
以调用链为例，通常咱们关注的场景是单条调用链的上下游追溯。但更多的状况是基于 Trace 数据进行统计分析，统计业务的申请量、谬误和耗时等黄金指标。
在构建追踪零碎时，咱们将其分为两类查问：一类是查问调用链，另一类是基于调用链生成的统计数据，咱们称之为指标。对于这些指标的计算，咱们能够将其前移以降低成本。具体而言，咱们引入了 Trace2Metric 的模式，将追踪数据进入解决链路后先进行解决，生成统计指标，比方某两个服务之间调用的数量、谬误数和耗时等指标，而后将其存储到指标存储系统中。至于其余原始 Trace 数据，能够通过之前提到的冷热数据形式进行解决，或以低成本的形式全量存储，例如去掉所有索引，只存储原始文本数据。
通过这样的形式分流数据，咱们在用户端通过可视化零碎进行查问时，更频繁地查问的是指标，而较低频的查问则是原始 Trace 数据。因而，在整体上升高了低频查问的存储老本，而高频查问的指标是聚合的，所以指标量也较小。通过这样的解决模式，咱们能够逐渐演进数据处理链路。
3.5.2 Log2Metric
在解决日志的指标时，思考模式与 Tracing 相似。实际上，日志更容易产生指标，特地是拜访日志，如网关日志或业务的拜访日志。这类日志通常须要统计整体业务或基于业务维度的数据，而单点查问很少。例如，统计哪些用户拜访了哪个业务零碎。因而，在采集日志数据后，咱们能够间接进行产生指标的解决。
在开源社区中已有相干的计划，如 Vector 模式，它对日志进行前置解决并生成指标。后续的存储形式与后面的 Trace 相似。
综上所述，咱们次要从以上几个维度思考来升高存储老本。
3.6 关键点 5：观测数据全局聚合查问
3.6.1 利用场景
数据的应用取决于存储状态。以指标为例，业务指标的数据可能存在几种场景。
跨账号的数据聚合查问：在云上可能存在不同账号的数据，每个账号对应不同的业务团队。然而在整体视角下进行可观测时，须要将相干数据聚合在一起进行可视化、告警等操作。
跨 Region 的数据聚合查问：从技术角度来看，可能存在跨地区、甚至跨国的数据查问需要。例如，北京可能有相干业务，杭州也有相干业务，北美也有相干业务。在观测整个业务零碎时，须要从这些不同地区甚至跨国 Region 查问相应的数据。
跨实例 (数据域) 的数据聚合查问：这个场景颗粒度更小，是数据的多租存储，即分不同的实例存储。此时最根底的粒度则是跨实例（数据域）。比方，某个实例存储后端服务的观测数据，另一个实例存储前端和 APP 的观测数据，还有一个实例存储云服务的观测数据。在做全栈观测时，须要将不同场景的数据进行聚合查问。
3.6.2 解决思路
为了实现这一指标，咱们须要抉择适合的技术来进行聚合查问。那么聚合查问是这么做的？
这里得益于开源标准，在指标解决的链路中，以 Prometheus 标准为主。该标准定义了丰盛的算子和查问语法。所有 PromQL 的查问语法进入到聚合查问实例后，就会拆解外面的每个算子，并将其发送到指标数据存储实例进行计算。而后将这些数据从新流回聚合实例进行聚合，并响应给用户。对于用户来说，这种计算和汇总的逻辑是通明的，因为他们只须要提供一个查问语法即可。同时，通过指标加标签的机制，咱们能够很好地分辨出数据的独特标签、差异化标签，从而理解这些数据的起源。这种模式可能帮忙咱们构建不同场景的可观测性视图。
3.7 关键点 6：构建无处不在的可观测基础设施
有了采集、存储、查问等基础设施后，构建全栈的可观测能力就必然须要面向场景。
在场景方面，通常能够分为基础设施的观测、利用的实时观测、前端的观测、APP 的观测以及被动的云拨测等。这些观测点都能从可观测平台进行分类。
在具体的业务场景中，则不须要思考这些，间接依据业务状态抉择适宜的观测形式。在提供这些能力时，咱们要思考开源的兼容性。因而，以开箱即用的形式提供开源和云服务的观测计划是十分重要的。开箱即用意味着每个场景的告警、大盘数据源、数据采集和解决规定等都以独立的聚合计划的模式间接可用。这对于构建可观测平台是一个重要参考。咱们提供给开发者和业务团队的，不能仅仅是技术的基础设施，而是应该是基于开源视角、业务视角和公共服务视角的最佳实际，以包装好的形式提供给平台用户应用。同时这种包装须要是标准化，可扩大的，咱们的研发甚至是用户能够依据需要随时定义新的插件，利用平台已有的能力，造成可复用的解决方案。
04 可观测平台的实际和落地成果
4.1 本身实际：阿里云构建全域 SLA 可观测
作为一个寰球散布的业务零碎，阿里云云原生可观测团队须要关注本身的观测和升高用户故障发现的工夫。为此，咱们须要构建一个全面的可观测团队视图。涵盖几个要害维度的数据：SLA 可用性、老本和稳定性、用户经营（用户规模、新增用户数量等）。
从这些需要中能够看到，咱们的观测需要是狭义上的全栈可观测。从 SRE、稳定性、业务经营等多个维度建设观测视图。
再细分 SLA 的可观测性需求，它波及到了寰球不同地区的数据采集、存储和应用侧的聚合查问。再依据不同的业务状态抉择不同的观测伎俩。在数据层面，咱们对立进行用户、地区和业务域等维度打标和数据查问。
对于咱们的业务散布，一个是管制面，一个是数据面，咱们须要针对不同的维度进行面向用户的聚合。在管制面中，咱们关注用户的操作，例如开明哪些实例等。在数据链路中，咱们关注每个用户在特定环境中的数据采集、存储和查问状况。利用各种观测技术手段，咱们能够从下往上进行聚合，最终造成残缺的观测视图。咱们能够通过两个截图来阐明。
第一个截图展现了 Agent 采集侧的 SLA 观测大盘，反对从用户维度、地区维度和用户环境维度观测数据采集状态，发现故障域，以及通过指标、日志等伎俩间接定位采集细节状态，达到洞察故障的成果。
第二个截图展现了存储侧的聚合数据，能够让咱们间接看到 SLA 的状况。反对从用户维度、地区维度和用户实例维度观测数据写入 SLA，先于用户发现写入环节故障。
即便咱们反对用户工单的同学具备不同的技术背景，也能够通过全栈观测大盘疾速发现用户问题，解决效率大大提高。咱们外部数据统计，通过建设多维度的观测大盘，整体故障洞察效率晋升了 50%。
4.2 用户实际：传音的全栈可观测实际
作为“非洲手机之王”，传音从事以手机为外围的智能终端的设计、研发、生产、销售和品牌经营，是新兴市场消费者青睐的智能终端产品和挪动互联服务提供商。据 IDC 报告显示 2021 年占据非洲智能手机出货量的 47.9%。传音挪动互联广告平台是传音控股的重要业务之一，是非洲最为支流的营销平台之一。
客户痛点：
在技术架构方面，传音控股采纳 Spring Cloud 进行全面微服务化，利用运行在阿里云容器服务 ACK 之上，并散布在欧洲、亚洲等多个地区，真正实现了多地区服务体系。对于该体系而言，要构建残缺的可观测体系，挑战十分大。
需要概述：
- 可观测性应笼罩从研发到生产的全周期。
- 同时须要监控寰球多个容器集群，云服务基础设施。
- 买通利用和基础设施观测，对立观测调用链和性能、可用性指标。
计划概述：
- 自建流水线数据采集零碎，通过 Grafana 展现利用构建数据
- 采纳 ARMS Prometheus 产品监控容器集群和利用性能及调用链，集成 Grafana 实现多集群对立监控
- SLS 产品实现业务日志、利用日志、容器日志的采集 / 存储 / 展现，并通过查问语句生成指标，在 Grafana 中展现
- 对立采集云服务观测数据，联合根底利用数据对立观测。
落地功效：
传音在建设全新的可观测技术能力后，不仅晋升了问题诊断效率，还晋升了用户体验。在此基础上，联合其余云原生新技术计划，业务上线效率进步了 60%，对于高效业务翻新起到了至关重要的作用。
05 总结与瞻望
开源技术和开源社区的倒退带来了标准化，笼罩了全栈技术和全栈业务方向的数据收集、存储和可视化等方面。而可观测性的厂商推出了全栈可观测的综合计划，引领用户实际，使得全栈状态更易实现。在此基础上，全栈可观测的实际案例得以在更多业务组织中落地。
当然利用可观测性技术带来了业务能见度、决策反对、老本优化和组织单干改良等收益，但同时，大多数业务组织也面临着技术复杂性、老本管制、组织文化改革、数据管理等方面的挑战。
咱们能够看到，越来越多的企业正在克服这些难题，让可观测技术冲破技术层面，进入业务层面，并失去更加宽泛的落地。可观测，无处不在！
作者介绍
阿里云智能技术专家——曾庆国（悦达）
TakinTalks 社区专家团成员。KubeVela 社区 Maintainer。长期从事云原生可观测、利用继续交付、基础设施治理等云原生畛域，积攒大量基于 Kubernetes 的云原生利用治理平台建设教训和可观测畛域实践经验。曾帮忙工业互联网、金融和企业办公等多个行业头部用户实现云原生 DevOps 转型。ArchSummit、Gopher、SDCon、A2M 等大会讲师。
本文依据作者在「TakinTalks 稳定性社区」公开分享整顿而成
点击立刻收费试用云产品 开启云上实际之旅！
原文链接
本文为阿里云原创内容，未经容许不得转载