前言
云原生时代，企业从单体架构发展到分布式架构，广泛采用微服务、容器、Serverless等部署方式，IT基础设施变得愈发不可控。这导致传统的监控技术和工具很难跟踪这些分布式架构中的通信路径和相互依赖关系，更别提排查问题并定位根本原因了。
Gartner认为数字化转型以业务为中心，服务和用户体验是关键目标。而IT监控以系统可用为中心，仅关注系统可用性指标对于转型中的企业而言是一场灾难。到2023年，依赖于“正常运行时间”指标的监控实践将抑制90%的转型计划。
当监控无法再单独以运维的视角、被动地解决故障为目标，而要追随IT架构的改变和云原生技术的实践，融入开发与业务部门的视角，具备比原有监控更广泛、更主动的能力，“可观测性”概念诞生了。
什么是可观测性
可观测性（Observability）一词最早出现在控制论领域，有着几十年的历史。随着云原生时代的到来，2018年，CNCF率先将可观测性一词引入IT领域，并称可观测性是云原生时代必须具备的能力。自此，“可观测性”逐渐取代“监控”，成为云原生技术领域最热门的话题之一。
我们先看一下*对于可观测性的定义：
控制理论中的可观察性（observability）是指系统可以由其外部输出推断其其内部状态的程度。系统的可观察性和可控制性是数学上对偶的概念。可观察性最早是匈牙利裔工程师鲁道夫·卡尔曼针对线性动态系统提出的概念。若以信号流图来看，若所有的内部状态都可以输出到输出信号，此系统即有可观察性。
*
在正式介绍可观测性之前，我们先简单介绍一下监控、可观测性：
监控（Monitoring）：收集、分析和使用信息来观察一段时间内的运行进度，并且进行相应的决策管理的过程，监控侧重于观察特定指标。
可观测性（Observability）：通过分析系统生成的数据理解推演出系统内部的状态。
监控发展历程
互联网发展早期的监控系统，主要是指基于SNMP（简单网络管理协议）的网络监控和系统（主要指操作系统）监控。这个时候的互联网应用都很简单，只有网络设备和操作系统可以提供标准的SNMP服务，一些Web服务器、中间件也支持通过SNMP获取状态，但不是很完善。设备提供商如思科、IBM、HP等提供一些设备监控产品。
随着互联网发展，一些开源监控系统开始在互联网公司得到应用，如Zabbix、Nagios、StatsD、RRDTool、Ganglia/Graphite等，同时Google通过《Google SRE》向业界介绍了其内部SRE（Site Reliablity Engineering）的工程实践以及Borgmon监控系统，受此影响SoundCloud公司开源了Prometheus监控系统，成为即Kubernetes之后第二个加入CNCF基金会的项目，成为云原生监控系统事实上的标准。
随着微服务及容器化的普及，服务力度细化，不同的服务模块甚至由不同的语言开发，运行在不同云环境，排查定位系统问题的难度呈指数级扩散，DevOps实践让开发工程师和运维工程师共同对服务的稳定性负责，研发开始引入全链路跟踪系统，帮助快速定位问题；同时也需要在研发过程中输出更多辅助定位系统问题的应用日志。
至此指标、日志、跟踪都已经得到广泛应用，2018年CNCF提出可观测性分组，将监控、日志和跟踪相关的项目都归入可观测性领域，后来又引入了混沌工程。
可观测性
随着分布式架构渐成主流，可观测性（Observability）一词也日益频繁地被人提起。最初，它与可控制性（Controllability）一起，是由匈牙利数学家 Rudolf E. Kálmán 针对线性动态控制系统提出的一组对偶属性，原本的含义是“可以由其外部输出推断其内部状态的程度”。
在学术界，虽然“可观测性”这个名词是近几年才从控制理论中借用的舶来概念，不过其内容实际在计算机科学中已有多年的实践积累。学术界一般会将可观测性分解为三个更具体方向进行研究，分别是：事件日志、链路追踪和聚合度量，这三个方向各有侧重，又不是完全独立，它们天然就有重合或者可以结合之处，2017 年的分布式追踪峰会（2017 Distributed Tracing Summit）结束后，Peter Bourgon 撰写了总结文章《Metrics, Tracing, and Logging》系统地阐述了这三者的定义、特征，以及它们之间的关系与差异，受到了业界的广泛认可。
Gartner 将可观测性定义为软件和系统的一种特性，它允许管理员收集有关系统的外部和内部状态数据，以便他们回答有关其行为的问题。然后，I&O、DevOps、SRE、Support等团队可以利用这些数据来调查异常情况，参与可观察性驱动的开发，并提高系统性能和正常运行时间。虽然可观察性处于早期阶段，截至 2020 年只有不到 10% 的企业采用它，但 Gartner 预测，到 2024 年，30% 的基于云架构的公司将采用可观察性技术。
可观测性描述的就是“观测-判断-优化-再观测”这个闭环的连续性、高效性。如果只有观测而无法基于观测做出判断，则不能称其具备可观测性。如果只有经验判断而没有数据支撑，也不能称其具备可观测性，这样会导致组织高度依赖个人能力而带来管理风险。如果优化之后无法反馈到观测上，或者因优化引入新的技术而导致无法观测，则其可观测性不可持续。如果在观测、判断、优化的闭环中需要付出很高的成本和承担很大风险，则其可观测性的价值为负。
所以，当我们在谈可观测性的时候，其实更多考虑的是观测者、管理者的感受，也就是说在我们遇到问题的时候，能否轻而易举地在观测平台找到答案，没有阻力也没有困惑，这就是可观测性，谷歌给出可观测性的核心价值很简单：快速排障（troubleshooting）。
监控与可观测性区别
监控与可观测性的区别到底是啥？简单可以概括一下：
监控
是您为提高系统的可观测性而执行的操作
可观测性
是该系统的一个属性,如功能性或可测试性
事实上，如果我们可以从积极地观察一个单一的度量标准，来判断哪些变化表明存在问题——那么这就是监控。但如果一个系统发出有关其内部状态的有用数据，那么它就具有可观测性，这在确定根因时是至关重要的。
从性能上看，监控和可观测性之间的区别可从以下四个方面进行区分：
以故障管理为例，“监控”的重点在于监视特定的指标，有助于我们回答“何时何地正在发生什么”这个问题；而可观测性的重点在于能够帮助团队在多云环境中了解上下文发生的事情，以检测和解决问题的根本原因，有助于我们回答“何时何地正在发生什么”以及“为什么会发生该事件”这两个问题。因此，可以说，在故障管理角度，相比较于监控，可观测性的价值在于快速排障。
虽然可观测性是由传统监控发展而来，但是他们有着本质的不同。
传统监控更多的是指运维自动化工具，主要用途是替代人自动监控系统运行情况，在系统发生异常时告警，最终还是需要人工去分析异常、故障诊断和根因分析。
但现代IT系统的关键词是分布式、池化、大数据、零信任、弹性、容错、云原生等，越来越庞大，越来越精细，越来越动态，同时也越来越复杂。通过人去寻找各种信息的关联性，再根据经验判断和优化，显然是不可行的，耗时耗力还无法找到问题根因。
可观测性不仅包含传统监控的能力，更多的是面向业务，强调将业务全过程透明化的理念，实现全景监控、智能运维和自修复能力等体系化的服务能力。
有业界专家一句话总结传统监控与可观测性的区别：“监控告诉我们系统的哪些部分是工作的；可观测性告诉我们那里为什么不工作了。”
监控与可观测性关联
其实监控就是做到了告警&视图，如果你是运维大佬估计深有感触，配配告警，展示下Cpu信息，diskIO等信息就完事儿了，可下图很明显可以看出，可观测不但包含告警和概览试图，还包括了排错、剖析、关联，全覆盖的一种场景。
IT领域中的监控手段已经存在几十年，当我们想要了解系统状态的时候，会很自然地搭建监控系统，通过监测系统的各项指标，以仪表盘的形式进行体现；当想了解系统内业务状态的时候，通过业务日志进行业务分析与定位；当想了解分布式系统事务状态的时候，通过APM服务监测事务的每一个环节指标，从而进行系统事务监测提升性能；当想分析系统指标或者业务指标在一定时间段的特征时，通过AIOPS手段对有规律数据进行异常分析、关联分析，又或者是根因分析。这些手段，可以看出，监控，是指通过收集、分析和使用信息来观察系统或业务在一段时间内的运行情况，并进行相应的决策管理，侧重于观察特定的指标信息。而可观测是通过分析系统生成的数据，并加以理解，从而展示出系统内部的状态。
在监控运维领域里，尤其是云原生领域带来的更精细、更复杂的系统架构，常常遇到这些情况：
- 某个指标突然持续飙升或骤降，但不清楚具体原因，因而只能根据经验一一排查；
- 监控仪表盘一切正常，但系统服务仍在某些时候会被上“系统ICU”，解决进度较缓；
- 监控大屏非常多，指标丰富，却不能反应出业务的真实情况。
监控模式帮助我们解决了很多问题。满屏的仪表盘，及时的告警方式，精细的日志、链路数据，我们在这些指标数据中寻找着可能的关联性，利用复杂的日志查询条件来验证自己的猜想，不断切换各种定位工具，但我们仍对系统一知半解。传统的系统使用上述方式相对有效及时，但在云原生领域，通过人为寻找关键信息，分析信息关联性，往往耗时耗力。
在这种复杂监控环境下，如何解决信息关联性，把之前需要人为关联比对的操作通过程序系统化，洞若观火地基于指标、日志、调用链数据呈现出系统的全貌，这才是可观测应该做的。
通过上面的阐述，我们可以看出，可观测性是监控的扩展，监控是可观测数据的基础，可以从三个维度对可观测性进行理解，如下图所示：
首先，监控到可观测性是从黑盒到白盒的转变。我们构建的监控系统，往往是注重结果，也就是是否产生告警，而对正常指标不太关心。而可观测性，是从系统内部状态的展示来呈现系统问题出现的原因。
其次，监控到可观测性是从基础资源到服务方向的转化。基础资源是指各项业务指标，以指标情况，判定系统状态，而云原生时代，需要暴露业务服务之间的调用链关系，通过更细粒度进行展现。
最后，监控到可观测性的处理方式是从被动到主动的转换。监控领域，通过告警信息推动运维人员去查看系统，或者运维人员被动式地查看具体监控详情。而当系统处于全开放可观测状态时，系统会自动更新内部状态，运维人员可极其方便的了解系统内部运行情况，主动发现问题。
通过数据关联，将系统白盒化呈现，做时间+空间上的关联。可观测性最流行的数据源是上文提到的指标、日志和调用链。而市场上这三个维度的工具其元数据信息不尽相同，梳理和映射这些数据信息是庞杂、难维护、不可持续的。在整合的过程中，会发现多套方案交织在一起，维护代价太大，各组件间数据不互通，无法充分发挥价值，一旦上线后，后续替换的代价无法估量，并且对云原生领域不太友好。
监控能够检测到系统中的错误，可以说是外部对业务应用系统的主动行为，而可观测性能够理解问题发生的原因，也就是说在增添了业务应用系统自身的要求的同时，还建立应用运行时产生的数据之间的关联。
故而，从某个意义上来说，监控是可观测性的子集和功能，可观测性是监控的超集和延展。换句话而言，一个系统只有在可观测的情况下才能被监控。
可观测性三大维度
CNCF将可观测性分解为三个更具体方向进行研究，分别是：事件日志、链路追踪和聚合度量。
日志（Logging）
日志的职责是记录离散事件，通过这些记录事后分析出程序的行为，譬如曾经调用过什么方法，曾经操作过哪些数据，等等。打印日志被认为是程序中最简单的工作之一，调试问题时常有人会说“当初这里记得打点日志就好了”，可见这就是一项举手之劳的任务。输出日志的确很容易，但收集和分析日志却可能会很复杂，面对成千上万的集群节点，面对迅速滚动的事件信息，面对数以 TB 计算的文本，传输与归集都并不简单。对大多数程序员来说，分析日志也许就是最常遇见也最有实践可行性的“大数据系统”了。
在业界中，事件日志可观测产品也已经是一片红海。日志管理方案大都包含日志收集、日志聚合、日志存储与分析几个模块，具体过程是日志收集工具与应用程序容器一起运行，并直接从应用程序收集消息，然后将消息转发到*日志存储以进行汇总和分析。
在这方面Elastic Stack日志解决方案独占鳌头，几乎覆盖了日志管理的全流程，其中一大变数是用于日志聚合、过滤等业务的Logstash效能较差，在未来可能会被CNCF孵化的Fluentd取代。
更多的日志组件可以参考：
追踪（Tracing）
单体系统时代追踪的范畴基本只局限于栈追踪（Stack Tracing），调试程序时，在 IDE 打个断点，看到的 Call Stack 视图上的内容便是追踪；编写代码时，处理异常调用了 Exception::printStackTrace()方法，它输出的堆栈信息也是追踪。微服务时代，追踪就不只局限于调用栈了，一个外部请求需要内部若干服务的联动响应，这时候完整的调用轨迹将跨越多个服务，同时包括服务间的网络传输信息与各个服务内部的调用堆栈信息，因此，分布式系统中的追踪在国内常被称为“全链路追踪”（后文就直接称“链路追踪”了），许多资料中也称它为“分布式追踪”（Distributed Tracing）。追踪的主要目的是排查故障，如分析调用链的哪一部分、哪个方法出现错误或阻塞，输入输出是否符合预期，等等。
追踪方面的情况与日志、度量有所不同，追踪是与具体网络协议、程序语言密切相关的，收集日志不必关心这段日志是由 Java 程序输出的还是由 Golang 程序输出的，对程序来说它们就只是一段非结构化文本而已，同理，度量对程序来说也只是一个个聚合的数据指标而已。但链路追踪就不一样，各个服务之间是使用 HTTP 还是 gRPC 来进行通信会直接影响追踪的实现，各个服务是使用 Java、Golang 还是 Node.js 来编写，也会直接影响到进程内调用栈的追踪方式。这决定了追踪工具本身有较强的侵入性，通常是以插件式的探针来实现；也决定了追踪领域很难出现一家独大的情况，通常要有多种产品来针对不同的语言和网络。近年来各种链路追踪产品层出不穷，市面上主流的工具既有像 Datadog 这样的一揽子商业方案，也有 AWS X-Ray 和 Google Stackdriver Trace 这样的云计算厂商产品，还有像 SkyWalking、Zipkin、Jaeger 这样来自开源社区的优秀产品。
更多产品可以参考：
度量（Metrics）
度量是指对系统中某一类信息的统计聚合。譬如，证券市场的每一只股票都会定期公布财务报表，通过财报上的营收、净利、毛利、资产、负债等等一系列数据来体现过去一个财务周期中公司的经营状况，这便是一种信息聚合。Java 天生自带有一种基本的度量，就是由虚拟机直接提供的 JMX（Java Management eXtensions）度量，诸如内存大小、各分代的用量、峰值的线程数、垃圾收集的吞吐量、频率，等等都可以从 JMX 中获得。度量的主要目的是监控（Monitoring）和预警（Alert），如某些度量指标达到风险阈值时触发事件，以便自动处理或者提醒管理员介入。
云原生监控指标可观测产品大都是从传统的监控产品发展而来的，传统监控中Zabbix以其高可用和图形化展示而广受欢迎。
而在云原生时代，CNCF孵化的监控工具Prometheus取代了以Zabbix为代表的众多传统监控工具，已基本成为云原生监控体系通用的解决方案，并可以通过配合Grafana工具实现监控数据图形化进行可视化分析。
更多产品可以参考：
Opentelemetry详解
针对上述可观测性三大组件我们可以比较快速的搭建一个可观测性系统。但是真正用起来会发现各种各样的问题。总结起来有如下几点：
- 组件繁多: 针对Metrics, Traces, Logs三种数据，往往需要搭建三套独立的系统，内部涉及的组件更多，维护成本很高。
- 数据不互通：同一个应用不同类型的数据被存储在相互独立的系统，数据不互通，难以发挥数据最大的价值。
- 厂商绑定：一些商业产品没有遵守社区标准，在数据采集、传输、存储、可视化、告警等阶段都可能与厂商绑定。后续更换方案的成本巨大。
针对以上问题，CNCF社区推出了OpenTelemetry项目。该项目雄心勃勃，旨在统一Metrics、Logs、Traces三种数据，实现可观测性大一统。
OpenTelemetry 最核心的功能是产生、收集可观察性数据，并支持传输到各种的分析软件中，整体的架构如下图所示，其中 OTel SDK 用于产生统一格式的可观察性数据，OTel Collector 用来接收这些数据，并支持把数据传输到各种类型的后端系统。
OpenTelemetry的诞生给云原生可观测性带来革命性的进步，包括：
- 统一协议：OpenTelemetry 为我们带来了 Metrics、Traces、Logs（规划中）的统一标准，三者都有相同的元数据结构，可以轻松实现互相关联。
- 统一 Agent：使用一个 Agent 即可完成所有可观察性数据的采集和传输，不需要为每个系统都部署各种各样的 Agent，大大降低了系统的资源占用，使整体可观察性系统的架构也变的更加简单。
- 云原生友好：OpenTelemetry 诞生在 CNCF，对于各类的云原生下的系统支持更加友好，此外目前众多云厂商已经宣布支持 OpenTelemetry，未来云上的使用会更加便捷。
- 厂商无关：此项目完全中立，不倾向于任何一家厂商，让大家可以有充分的*来选择、更换适合自己的服务提供商，而不需要收到某些厂商的垄断或者绑定。
- 兼容性：OpenTelemetry 得到了 CNCF 下各种可观察性方案的支持，未来对于 OpenTracing 类、OpenCensus、Prometheus、Fluntd 等都会有非常好的兼容性，可以方便大家无缝迁移到 OpenTelemetry 方案上。
OpenTelemetry定位是作为可观测性的基础设施，解决数据产生、采集、传输的问题，后面数据的存储与分析还是依赖各个后端系统。最理想的情况是能有一个后端引擎同时存储所有的Metrics, Logs, Traces数据，并进行统一的分析、关联、可视化。不过目前还没有厂商或开源产品实现了OpenTelemetry统一后端，当前还是不同数据分开存储，数据的统一展示与关联分析依然是一个很大的挑战。
现在已经有一些厂商开始相关的尝试。比如Grafana Labs推出的云原生日志系统Loki, 主要设计理念来源于Prometheus。通过Loki, 用户可以像分析Prometheus指标一样分析日志，也可以基于相同的Labels来关联Metrics和Logs数据。如下图所示，在同一个Grafana面板中，左右分别展示了相关的Metrics和Logs，用户可以方便的对数据进行关联分析。
Metrics、Traces、Logs涵盖了一个应用所能产生的大部分可观测性数据，足以让开发运维人员洞察应用的运行状态。但是在云原生场景下，这些还远远不够，人们需要更加全面的可观测性能力。具体如下：
- 容器洞察：除了容器应用的监控，人们往往还想知道集群拓扑是怎样的，依赖的底层基础设施和周边云服务是否运行正常。这些除了需要Metrics、Traces、Logs数据之外，还需要依赖云服务提供商去获取基础设施的信息。而这些信息的获取、清洗、存储、分析往往需要定制化的程序去构建。
- 主动巡检：除了被动的接收监控系统的告警信息之外，主动的检查整个系统健康状态，可以让人们对整个系统运行状态有更全面的理解。主动巡检能力要求可观测软件具备了解整个系统运行细节的能力，并且具备足够的知识库去评判系统。
- 容量规划与成本优化：云原生场景下，弹性给服务的运行带来了极大的灵活性，也带来了对容量规划和成本优化的需求。可观测性系统需要有能力给出最佳的容量规划与成本优化建议。
作为全球最大的云原生开源社区，CNCF推出的Open Telemetry以期实现理想状态下的大一统：统一Logs、Trace、Metrics三种数据协议标准，使用一个 Agent 完成所有可观测性数据的采集和传输，适配众多云厂商，兼容CNCF上众多的开源与商业项目。但是至今未有厂商或开源项目可以统一Open Telemetry后端，三种数据源的统一存储、展示与关联分析仍面临极大挑战，而解决以上问题的前提，仍然是统一数据源（数据格式）。
可观测性实践
为了实现可观测性，需要对系统和应⽤程序进⾏适当的⼯具来收集适当的遥测数据。可以通过构建⾃⼰的⼯具、使⽤开源软件或购买商业可观测性解决⽅案来设计可观测系统。
通常，实现可观测性涉及四个组件：
1.仪表
这些是测量⼯具，可从容器、服务、应⽤程序、主机和系统的任何其他组件收集遥测数据，从⽽实现整个基础架构的可⻅性。
2.数据关联
处理和关联从整个系统收集的遥测数据，从⽽创建上下⽂并为时间序列可视化启⽤⾃动化或⾃定义数据管理。
3.事件响应
这些⾃动化技术旨在根据随叫随到的时间表和技术技能将有关停电的数据提供给合适的⼈员和团队。
4.AIOps
机器学习模型⽤于⾃动聚合、关联事件数据并确定其优先级，使您能够过滤掉警报噪⾳，检测可能影响系统的问题并在发⽣事件时加速事件响应。
工具选型：
- Metrics：常用Zabbix、Nagios、Prometheus，及相关高可用部署方案如Prometheus-operator、Thanos。
- Logging：ELK Stack、Fluentd、Loki等。
- Tracing：常用Jaeger、SkyWalking、Pinpoint、Zipkin、Spring Cloud Sleuth等。
- 可视化：Grafana。
核心设计理念：三者打通最大的价值是能做到全链路错误寻根，即从发现请求Metric指标异常，通过指标关联分析，并逐层下钻到明细Trace追踪和具体Error Log，全流程自动化从宏观到明细的错误发现和根因定位。
关键技术：
- 数据收集：如果是基于Prometheus生态，有丰富的Exporte可用，还可以自研相应的Exporter。如果基于文件日志收集，可考虑Flume、Fluentd等等。可尝试梳理完整的数据链路，来覆盖从终端发起、网关、业务、基础设施中间的每一层组件；可以不同的观测视角进行覆盖，比如Metrics、Traces、Logs、Exception Collection、Profiler、Debuger、Changelog等类别的数据或能力都已建设齐备；可以多种维度来观察系统，比如业务维度、资源瓶颈、关联组件等维度进行覆盖的建设。
- 数据分析：可基于Clickhouse SQL分析提炼日志指标，如果是Prometheus体系，也有丰富的PromQL可用来分析相关指标。针对Traces、Logs分析一般采用自研分析引擎，并与Metrics打通。数据分析环节要关联不同数据源的元信息，糅合以多维视角来构建查询界面。同时，我们也要关注如何在海量的原始数据中找到一些突出和异常的数据，一般需要建设一些流式检测和聚类分析的能力。
- 数据存储：Prometheus本身就是一款很好的时序数据库，但不支持分布式存储。一般采用远程存储引擎搭配使用，常用Clickhouse、InfluxDB等。Traces和Logs一般可采用Elasticsearch存储。数据存储环节要关注多种类型数据的存储和查询系统选型。最为常见的是Metrics、Traces、Logs相关的存储系统，这三者都有非常广泛的基础软件选型。其中相对棘手的是指标维度爆炸、日志和Trace存储成本及性能相关的问题，一般需要搭配预聚合、前采样和后采样、存储分级等策略来解决。
- 数据展示：数据最终呈现形式，需要契合可视化设计规划，支持上卷/下钻。大部分需求可采用Grafana呈现，Grafana提供了丰富的插件，支持丰富的数据库类型，也可基于Echarts自研。如果托管公有云，可充分利用公有云自有的体系，不过有些需要单独付费。
可观测工具系统的这些特性：
- 高可用：可观测系统作为稳定性的守卫者，本身要求更高的可靠性。
- 可伸缩：我们关注存储写入和查询能力的可拓展性，以支持更大的数据量级。
- 降成本：观测类数据会随着时间的推移逐渐失去价值，历史数据最好能低成本地失效或能对存储介质进行降级。
- 易运维：拥有一定的自动化能力或者本身架构足够简单。
其实技术选型没什么特定的标准，每个企业不同阶段可能有不同的选择，适合自己的才是最好的，这里总结几点心得：
- 控制成本预算，企业一般需要从自身的发展阶段实际情况考虑，不必一上来就整全链路可观测性，也许初期只用传统的Zabbix就满足需求了。理性按需选择，大可不必盲从主流。
- 拥抱开源，初期一般采用开源产品，开箱即用，搭顺风车。另外，选型时还需要考虑周边生态的丰富度。
- 根据团队技术栈选择，中间件、业务服务、云原生、物理机监控等选型都要贴合团队已有的技术栈。
可观测性业界动态
根据上文的分析不难发现，可观测性问题相对复杂，并且没有开箱即用的最佳方案。为了应对云原生场景下复杂的可观测性问题，各大云计算厂商采用了不同的策略。有些采用多种产品组合的方式，针对不同场景，为客户提供不同的解决方案，比如AWS有CloudWatch、AMP、AMG等产品组合，而阿里云有ARMS、链路追踪、日志服务SLS等；有些厂商则提供了统一的解决方案，比如Azure monitor，Vmware Tanzu Wavefront，华为云CIE等。
AWS：从CloudWatch到AMP/AMG，全面拥抱开源
CloudWatch一直以来都是AWS最主要的监控服务，包含了监控、告警、日志、事件等功能。为了应对云原生可观测性场景，CloudWatch推出了Container Insights功能，并支持Prometheus指标接入。Container Insights为用户构建了Prometheus指标面板，应用性能监控、集群拓扑图等功能。
另外，AWS还与Grafana Labs合作，推出了两款云原生容器监控服务。一款是完全托管的Grafana服务Amazon Managed Service for Grafana（AMG），一款是完全托管兼容Prometheus的监控服务Amazon Managed Service for Prometheus (AMP)。同时，AWS跟进OpenTelemetry项目，发布了定制版的Otel Collector: AWS Distro for OpenTelemetry（ADOT）。通过ADOT、AMP、AMG的组合，AWS解决了安全性、高可用性、扩展性等问题，让客户在AWS上可以借助开源社区的优势与力量实现云原生可观测性。
从CloudWatch Container Insights到AMG/AMP，再到AWS Distro for OpenTelemetry，可以看出AWS在不断增强CloudWatch能力的同时，积极主动的与开源社区合作，并利用社区生态构建云原生可观测性产品。