从Opentracing、OpenCensus 到 OpenTelemetry，看可观测数据标准演进史
简介
伴随着分布式应用、Serverless 应用被越来越多开发者及企业所接受，但其背后所隐藏的运维问题也逐渐凸显出来--微服务架构中请求链路过长从而导致问题定位时间长，运维想要日常监控也非常困难。以一个具体问题举例，在分布式应用中完成一个单一用户请求可能会需要多个不同的微服务处理，这其中任何一个服务失败或性能拉垮，都会对用户请求响应造成极大影响。随着业务不断扩张，这个调用链也越来越复杂。仅凭借打印日志或 APM 性能监控很难做到全景浏览或者一钻到底。对于问题排查或性能分析时，这无异于盲人摸象。
面对这样的问题，Google 发表了论文《"Dapper - a Large-Scale Distributed Systems Tracing Infrastructure"》[1]介绍他们的分布式跟踪技术，并认为分布式跟踪系统应该满足以下业务需求：
- 性能低损耗:分布式系统对服务的性能损耗尽可能做到忽略不计,尤其是哪些对性能敏感应用
- 低侵入:尽可能做到业务代码无侵入
- 快速扩展:苏子和业务或微服务规模快速扩大
- 实时展现:低延时采集数据,实时监控系统,对系统的异常状态做出快速的反应
除了以上要求，该论文也针对分布式追踪的数据采集、数据持久化、数据展示三个核心环节进行了完整阐述。这其中，数据采集指在代码中埋点，设置请求中需要上报的内容。数据持久化指将上报的数据落盘存储。数据展示则是根据 TraceID 查询与之关联的请求在界面上呈现。
也是随着这篇论文的诞生，分布式追踪（Distributed Tracing)被越来越多人接受，技术概念逐渐兴起。相关产品如雨后春笋般涌现，Uber 的 Jaeger、Twitter 的 Zipkin 等分布式追踪产品声名大噪。但在这过程中也带来了一个问题：虽然每个产品都有自己一套数据采集标准和 SDK，但大多都是基于谷歌 Dapper 协议，只是实现不尽相同。为了解决这个问题，OpenTracing 和 OpenCensus 诞生。
OpenTracing
cloud native
在 OepnTracing 之前，一方面，很多分布式追踪系统通过使用不兼容 API 的应用程序级检测进行实现，这使得开发人员对应用与任何特定的分布式跟踪紧密耦合，都会感到不安。另一方面，这些应用程序级检测 API 具有非常相似的语义。为了解决不同的分布式追踪系统 API 不兼容问题，或者说追踪数据从一个库到另一个库和一个进程到下一个进程传递过程中的标准化问题，诞生了 OpenTracing 规范。位于应用程序/类库和追踪或日志分析程序之间的轻量级标准化层。
OpenTracing 的优势在于制定了一套无关厂商、无关平台的协议标准，使开发人员只需要修改 Tracer 就可以更迅捷的添加或更换底层监控的实现。也是基于这一点，2016 年云原生计算基金会 CNCF 正式接纳 OpenTracing，顺利成为 CNCF 第三个项目。而前两个项目都已成为云原生及开源领域的事实标准--Kubernetes 和 Prometheus。由此也可以看到行业对于可观测及统一标准的重视程度。
OpenTracing 由 API 规范、实现该规范的框架和库，以及项目文档组成，并进行以下努力：
- 后台无关的 API 接口标准化：被追踪的服务只需要调用相关 API 接口，就可被任何实现这套接口的追踪后台支持。
- 对跟踪最小单位 Span 管理标准化：定义开始 Span，结束 Span 和记录 Span 耗时的 API。
- 进程间跟踪数据传递方式标准化：定义 API 方便追踪数据的传递。
- 对多语言应用支持的标准化：全面覆盖 GO、Python、Javascript、Java、C#、Objective-C、C++ 、Ruby、PHP 等开发语言。它支持 Zipkin、LightStep、Appdash 跟踪器，并可以轻松集成到 GRPC、Flask、DropWizard、Django和Go Kit 等框架中。
- trace:一个完成请求链路
span:一次调用过程系统中具有多个开始时间和执行市场的逻辑单元,并包含多个状态
- An operation name - 操作名称
- A start timestamp - 起始时间
- A finish timestamp - 结束时间
- Span Tag - 一组键值对构成的 Span 标签集合。
- 键值对的键必须为 String，值可以是字符串、布尔或数字类型。
- Span Log:一组Span的日志集合 每次 Log 操作包含一个键值对以及时间戳。键值对的键必须为 String，值可以是任意类型。
- References - Span 间关系 相关的零个或者多个 Span。Span 间通过 SpanContext 建立 References 关系。
- spanContext通过spancontext引用其他因果相关的span
openTracing目前定义了俩种类型的引用:ChildOf和FollowsFrom.这俩种引用类型都专门模拟了子span和父span之间的直接因果关系
ChildOf 关系中的父级 Span 要等待子 Span 返回，子 Span 执行时间影响了其所在父 Span 执行时间，父 Span 依赖子 Span 执行结果。除了串行的任务之外，我们的逻辑中还有很多并行的任务，它们对应的 Span 也是并行的，这种情况下一个父 Span 可以合并所有子 Span 执行结果并等待所有并行子 Span 结束。在分布式应用中某些上游系统不以任何方式依赖下游系统执行结果，例如，上游系统通过消息队列向下游系统发送消息。这种情况下，下游系统对应的子 Span 和上游系统对应的父级 Span 之间是 FollowsFrom 关系。
- 数据模型
在了解相关术语之后，我们可以发现 OpenTracing 规范中具备三个关键且互连的类型：Tracer、Span 和 SpanContext。OpenTracing 的技术模型，也就清晰起来：Trace 调用链通过归属于此调用链的 Span 来隐性定义，每次调用就称为一个 Span，每个 Span 都要带上全局的 TraceId 。Trace 调用链可以被认为是一个由多个 Span 组成的有向无环图（DAG 图），一条 Trace 中 Span 是首尾连接的。TraceID 及相关内容以 SpanContext 为载体，通过传输协议，遵循着 Span“路径”按序进行。以上可以看作分布式应用中一次客户端请求全过程，除了从业务视角的 DAG 图之外，为了更好的展示组件调用时间、先后关系等信息，我们也尝试基于时间轴的时序图去更好地展现 Trace 调用链。
实战
- 应用代码
开发人员可以使用 OpenTracing 来描述服务之间的因果关系，并添加细粒度日志信息。
- 库代码
采取中间控制请求的库可以与 OpenTracing 集成，例如，Web 中间件库可以使用 OpenTracing 为请求创建 Span，或者 ORM 库可以使用 OpenTracing 描述高级别的 ORM 语义，并执行特定 SQL 查询。
- RPC/IPC 框架
任何跨进程的子服务都可以使用 OpenTracing 来标准化追踪数据的格式。
5 相关产品
遵循 OpenTracing 协议的产品有 Jaeger、Zipkin、 LightStep 和 AppDash 等追踪组件，并可以轻松集成到 gRPC、Flask、Django 和 Go-kit 等开源框架中。
Opencensus
在整个可观测领域，为了更好的实现 DevOps，除了分布式追踪 Trace，运维人员开始关注 Log 和 Metrics。Metrics 指标监控作为可观测的重要组成部分，包括 CPU、内存、硬盘、网络等机器指标，gRPC 请求延迟、错误率等网络协议指标，用户数、访问数等业务指标。
OpenCensus 提供了统一的测量工具：跨服务捕获跟踪跨度 Span、应用级别指标 Metrics。
1 优势
- 相较于 OpenTracing 只支持 Traces，OpenCensus 支持 Traces 和 Metrics。
- 相较于 OpenTracing 制定规范，OpenCensus 不仅制定规范，还包含了 Agent 和 Collector。
- 家属团阵容相较 OpenTracing 更加庞大，获得 Google、微软支持。
2 做了什么
- 标准通信协议和一致的 API ：用于处理 Metrics 和 Trace。
- 多语言库支持：Java、C++、Go、.Net、Python、PHP、Node.js、Erlang 、Ruby。
- 与 RPC 框架的集成。
- 集成存储和分析工具。
- 完全开源并支持三方集成和输出的插件化。
- 不需要额外服务器或 Agent 来支持 OpenCensus。
3 核心术语介绍
除了沿用 OpenTracing 的相关术语之外，OpenCensus 也定义了一些新术语。
3 核心术语介绍
除了沿用 OpenTracing 的相关术语之外，OpenCensus 也定义了一些新术语。
- Tags
OpenCensus 允许在记录时将指标与维度相关联。从而能够从不同角度分析测量结果。
- Stats
收集库和应用记录的可观测结果，汇总、导出统计数据，并包括 Recording（记录）、Views（聚合度量查询）两部分。
- Trace
除了 Opentracing 所提供的 Span 属性之外，OpenCensus 还支持 Parent SpanId、Remote Parent、Attributes、Annotations、Message Events、Links 等属性。
- Agent
OpenCensus Agent 是一个守护进程，允许 OpenCensus 的多语言部署使用Exporter。与传统上为每个语言库和每个应用程序删除和配置 OpenCensus Exporter不同，使用 OpenCensus Agent，只需为其目标语言单独启用 OpenCensus Agent Exporter。对于运维团队而言，实现单个 exporte 管理并从多语言应用程序中获取数据，将数据发送到所选择的后端。与此同时，尽可能的减少反复启动或部署对于应用的影响。最后，Agent 还附带了“Receivers”。“Receivers”使 Agent 直通后端，去接收可观测数据并将其路由到所选择的 Exporter。比如 Zipkin、Jaeger 或 Prometheus。
Collector
Collector 作为 OpenCensus 的重要组成部分，由 Go 语言便编写，可以从任何可用 Receivers 的应用中接受流量，而不用关注编程语言以及部署方式，而这个好处显而易见。对于提供 Metrics 和 Trace 的服务或应用而言，只需要一个 Exporters 导出组件，就能从多语言应用中获取数据。
对于开发者而言，只需要管理维护单个 Exporter，所有应用都使用 OpenCensus Exporter 发送数据。与此同时，开发人员自由选择将数据发送到业务所需的后端，并随时进行更好。为了解决通过网络发送大量数据可能需要处理发送失败的问题，Collector 具有缓冲和重试功能，可确保数据完整性与可用性。
- Exporters
OpenCensus 可以通过各种 Exporter 实现将相关数据上传到各种后端，比如：Prometheus for stats、OpenZipkin for traces、Stackdriver Monitoring for stats and Trace for traces、Jaeger for traces、Graphite for stats。
4 相关产品
遵循 OpenCensus 协议的产品有 Prometheus、SignalFX、Stackdriver 和 Zipkin。
看到这里，我们可以看到从功能、特性等维度来评估上述两者。OpenTracing 和 OpenCensus 各有明显优缺点：OpenTracing 支持语言更多、对其他系统耦合性更低；OpenCensus 支持 Metrics、分布式跟踪，同时从 API 层一直到基础设施层都进行支持。对很多开发人员而言，选择困难症发作的同时，一个新的想法不断被讨论：是否能有一个能够将 OpenTracing 和 OpenCensus，并且能够支持 Log 日志相关可观测数据的项目呢？
OpnTelemetry
Cloud Native
在回答上一个问题时，我们先看看一个典型服务问题排查过程是怎样的：
- 通过各式各样预设报警发现异常（Metrics/Logs）
- 打开监控大盘查找异常现象，并通过查询找到异常模块（Metrics）
- 对异常模块以及关联日志进行查询分析，找到核心的报错信息（Logs）
- 通过详细的调用链数据定位到引起问题的代码（Tracing）
为了能够获得更好的可观测性或快速解决上述问题，Tracing、Metrics、Logs缺一不可。
与此同时，行业中已经有了丰富的开源及商业方案，其中包括：
- Metric：Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus
- Tracing：Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus
- Logs：ELK、Splunk、SumoLogic、Loki、Loggly。
有着五花八门的方案同时，各个方案也有着五花八门的协议格式/数据类型。不同的方案之间很难兼容/互通。与此同时，实际的业务场景中也会将各种方案混用，开发人员只能自己开发各类 Adapter 去兼容，
1 什么是 OpenTelemetry
为了更好的将 Traces、Metrics 和 Logs 融合在一起，OpenTelemetry 诞生了。作为 CNCF 的孵化项目，OpenTelemetry 由 OpenTracing 和 OpenCensus 项目合并而成，是一组规范、API 接口、SDK、工具和集成。为众多开发人员带来 Metrics、Tracing、Logs 的统一标准，三者都有相同的元数据结构，可以轻松实现互相关联。
OpenTelemetry 与厂商、平台无关，不提供与可观测性相关的后端服务。可根据用户需求将可观测类数据导出到存储、查询、可视化等不同后端，如 Prometheus、Jaeger 、云厂商服务中。
2 优势
OpenTelemetry 核心优势集中在以下部分：
- 完全打破各个厂商的 Lock-on 隐患
作为运维人员而言，发现工具不够用，但评估实现成本太高而无法切换时，一定会跳起来大骂厂商“狗贼又要谋害朕”。而 OpenTelemetry 的出现，旨在通过提供标准化 instrumentation 框架打破这种宿命，作为一个可插拔的服务，可以轻松添加常见的技术协议与格式，让服务选择更加自由。
- 规范的制定和协议的统一
OpenTelemetry 采用基于标准的实现方法。对标准的关注对于 OpenTelemetry 来说尤其重要，因为需要追踪跨语言的互操作性。许多语言都带有类型定义，可以在实现中使用，例如用于创建可重用组件的接口。包括可观测客户端内部实现所需要的规范，以及可观测客户端与外部通信所需实现的协议规范。具体包括：
- API：定义 Metrics、Tracing、Logs 数据的类型和操作。
- SDK：定义 API 特定语言实现需求，定义配置、数据处理和导出概念。
- 数据：定义 OpenTelemetry Line Protocol （OTLP）。虽然在 Opentelemetry中组件支持了 Zipkin v2 或 Jaeger Thrift 协议格式的实现，但都以第三方贡献库形式提供。只有 OTLP 是 Opentelemetry 官方原生支持的格式。
每种语言都通过其 API 实现规范。API 包含特定于语言的类型和接口定义，它们是抽象类、类型和接口，由具体的语言实现使用。它们还包含无操作（no-op）实现，以支持本地测试并为单元测试提供工具。API 的定义位于每种语言的实现中。正如 OpenTelemetry Python 客户端所述：“opentelemetry-api 包包括抽象类和无操作实现，它们组成了遵循规范的 OpenTelemetry API。”可以在 Javascript 客户端中看到类似定义：“这个包提供了与 OpenTelemetry API 交互所需的所有东西，包括所有 TypeScript 接口、枚举和 no-op 实现。它既可以在服务器上使用，也可以在浏览器中使用。”
- 多语言 SDK 的实现和集成
OpenTelemetry 为每个常见语言都实现了对应 SDK，将导出器与 API 结合在一起。SDK 是具体的、可执行的 API 实现。包含 C++、.NET、Erlang/Elixir、Go、Java、JavaScript、PHP、Python、Ruby、Rust、Swift。
OpenTelemetry SDK 通过使用 OpenTelemetry API 使用选择的语言生成可观测数据，并将该数据导出到后端。并允许为公共库或框架增强。用户可以使用 SDK 进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack 等）集成支持；这些包一般都是根据 opentelemetry-specification 里面的规范与定义，结合语言自身的特点去实现在客户端采集可观测数据的基本能力。如元数据在服务间、进程间的传递，Trace 添加监测与数据导出，Metrics 指标的创建、使用及数据导出等。
- 多语言 SDK 的实现和集成
OpenTelemetry 为每个常见语言都实现了对应 SDK，将导出器与 API 结合在一起。SDK 是具体的、可执行的 API 实现。包含 C++、.NET、Erlang/Elixir、Go、Java、JavaScript、PHP、Python、Ruby、Rust、Swift。
OpenTelemetry SDK 通过使用 OpenTelemetry API 使用选择的语言生成可观测数据，并将该数据导出到后端。并允许为公共库或框架增强。用户可以使用 SDK 进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack 等）集成支持；这些包一般都是根据 opentelemetry-specification 里面的规范与定义，结合语言自身的特点去实现在客户端采集可观测数据的基本能力。如元数据在服务间、进程间的传递，Trace 添加监测与数据导出，Metrics 指标的创建、使用及数据导出等。
- **
数据收集系统的实现**
在 Tracing 实践中有个基本原则，可观测数据收集过程需要与业务逻辑处理正交。尽量减少可观测客户端对原有业务逻辑的影响，Collector 是基于这个原则。OpenTelemetry 基于 OpenCensus Service 的收集系统，包括 Agent 和 Collector。Collector 涵盖采集（Collect）、转换（Transform）和导出（Export）可观测数据的功能，支持以多种格式（例如 OTLP、Jaeger、Prometheus 等）接收可观测数据，并将数据发送到一个或多个后端。它还支持在输出可观测数据之前，对其进行处理和过滤。Collector contrib 软件包支持更多数据格式和后端。
从架构层面来说，Collector 有两种模式。一种是把 Collector 部署在应用相同的主机内（如Kubernetes 的 DaemonSet），或者部署在应用相同的 Pod 里面（如Kubernetes 中的 Sidecar），应用采集到的遥测数据，直接通过回环网络传递给 Collector。这种模式统称为 Agent 模式。另一种模式是把 Collector 当作一个独立的中间件，应用把采集到的遥测数据往这个中间件里面传递。这种模式称之为 Gateway 模式。两种模式既可以单独使用，也可以组合使用，只需要数据出口的数据协议格式跟数据入口的数据协议格式保持一致。
- 自动代码注入技术
OpenTelemetry 也开始提供可以自动代码注入的实现，目前已经支持Java各类主流框架的自动注入。
- 云原生架构
OpenTelemetry 设计之初就已经考虑了云原生的特性，并且还提供了 Kubernetes Operator 用于快速部署使用。
3 OpenTelemetry 支持的数据类型
- Metrics
Metric 是关于一个服务的度量，在运行时捕获。从逻辑上讲，捕获其中一个量度的时刻称为 Metric event，它不仅包含量度本身，还包括获取它的时间和相关元数据。应用和请求指标是可用性和性能的重要指标。自定义指标可以深入了解可用性如何影响用户体验和业务。自定义 Metrics 可以深入理解可用性 Metrics 是如何影响用户体验或业务的。OpenTelemetry 目前定义了三个 Metric 工具：
- counter: 一个随时间求和的值，可以理解成汽车的里程表，它只会上升。
- measure: 随时间聚合的值。它表示某个定义范围内的值。
- observer: 捕捉特定时间点的一组当前值，如车辆中的燃油表。
- Logs
日志是带有时间戳的文本记录，可以是带有元数据结构化的，也可以是非结构化的。虽然每个日志都是独立数据源，但可以附加到 Trace 的 Span 中。日常使用调用时，在进行节点分析时出伴随着也可看到日志。
在 OpenTelemetry 中，任何不属于分布式 Trace 或 Metrics 的数据都是日志。日志通常用于确定问题根因，通常包含有关谁更改了内容以及更改结果的信息。
- Traces
Trace 指单个请求的追踪，请求可以由应用程序发起，也可以由用户发起。分布式 Tracing 是跨网络，跨应用的追踪形式。每个工作单元在 Trace 中被称为 Span，一个 Trace 由一个树形的 Span 组成。Span 表示经过应用程序所设计的服务或组件所做工作的对象，Span 还提供了可用于调试可用性和性能问题的请求、错误和持续时间的 Metrics。Span 包含了一个 Span 上下文，它是一组全局唯一标识符，表示每个 Span 所属的唯一请求。通常我们称之为 TraceID。
- Baggage
除了 Trace 的传播，OpenTelemetry 还提供了 Baggage 来传播键值对。Baggage 用于索引一个服务中的可观察事件，该服务包含同一事务中先前的服务提供的属性，有助于在事件之间建立因果关系。虽然 Baggage 可以用作其他横切关注点的原型，但这种机制主要是为了传递 OpenTelemetry 可观测性系统的值。这些值可以从 Baggage 中消费，并作为度量的附加维度，或日志和跟踪的附加上下文使用。
4 仅仅是第一步，还是一站式？
结合上面的内容，我们可以看到 OpenTelemetry 覆盖了各类可观测数据类型的规范定义、API 定义、规范实现以及数据的获取与传输。应用只需要一种 SDK 就可以实现所有类型数据的统一产生；集群只需要部署一个 OpenTelemetry Collector 便可以实现所有类型数据的采集。而且 Metrics、Tracing、Logging 的具有相同的 Meta 信息，可以做无缝关联。
OpenTelemetry 要解决的是可观测性数据统一的第一步，通过 API 和 SDK 来标准化可观测数据的采集和传输，OpenTelemetry 并不想对所有组件都进行重写，而是最大程度复用业界在各大领域常用工具，通过提供一个安全、无关平台、无关厂商的协议、组件、标准。其自身定位很明确：数据采集和标准规范的统一，对于数据如何去使用、存储、展示、告警，官方是不涉及的。但就可观测整体方案而言，OpenTelemetry 只完成了数据统一生产部分，后续如何存储、利用这些数据进行分析、告警等并没有明确提供相关方案，但这些问题又非常突出。
- 各类数据的存储方式
Metrics 可以存在 Prometheus、InfluxDB 或者各类时序数据库；Tracing 可以对接Jaeger、OpenCensus、Zipkin。但如何进行选型以及后续进行运维这些后端服务是个很难抉择的问题。
- 数据分析（可视化与关联）
对于所采集的数据如何进行统一分析？不同数据需要不同的数据平台进行处理，想要在统一平台显示 Metrics、Logging、Tracing 并实现三者关联跳转，需要很多定制开发工作。这对于运维而言是个很大的工作量。
- 异常检测与诊断
除了日常可视化监控之外，对应用异常检测和根因诊断是运维的重要业务需求，这时就需要把 OpenTelemetry 的数据融入到 AIOps 中。但对很多开发及运维团队而言，基础的 DevOps 都尚未完全落地，更何况更进一步的 AIOps。
5 最佳实践：通过 OpenTelemetry 接入应用实时监控服务 ARMS
针对上述问题，阿里云提供了应用实时监控服务 ARMS，帮助运维团队解决数据分析、异常检测与诊断问题。ARMS 支持多种方式接入 OpenTelemetry Trace 数据，您可以将 OpenTelemetry Trace 数据直接上报至 ARMS，或通过 OpenTelemetry Collector 转发。
（1）直接上报
- 通过 ARMS Java Agent 接入 OpenTelemetry Trace 数据 Java 应用推荐安装 ARMS Java Agent。ARMS Java Agent 内置了大量通用组件的链路埋点，能够自动上报 OpenTelemetry 格式的 Trace 数据，开箱即用，无需额外配置。具体操作，请参见监控 Java 应用[2]。
- 结合 ARMS Java Agent 与 OpenTelemetry Java SDK 上报 Trace 数据 v2.7.1.3 及以上版本的 ARMS Java Agent 支持 OpenTelemetry Java SDK 扩展。您在使用 ARMS Java Agent 自动获取通用组件 Trace 数据的同时，还可以通过OpenTelemetry SDK 扩展自定义的方法埋点。具体操作，请参见 OpenTelemetry Java SDK支持[3]。
- 通过 OpenTelemetry 直接上报 Trace 数据您也可以使用 OpenTelemetry SDK 进行应用埋点，并通过 Jaeger Exporter 直接上报 Trace 数据。具体操作，请参见通过 OpenTelemetry 上报 Java 应用数据[4]。
（2）通过 OpenTelemetry Collector 转发
- 通过 ARMS for OpenTelemetry Collector 转发 Trace 数据
在容器服务 ACK 环境下，您可以一键安装 ARMS for OpenTelemetry Collector，通过它进行 Trace 数据的转发。ARMS for OpenTelemetry Collector 实现了链路无损统计（本地预聚合，统计结果不受采样率影响），动态配置调参，状态管理以及开箱即用的 Trace Dashboard on Grafana，同时更加易用、稳定、可靠。
ARMS for OpenTelemetry Collector 的接入流程如下：
- 通过 ACK 控制台应用目录安装 ARMS for OpenTelemetry Collector。
- 登录容器服务管理控制台[5]。
- 在左侧导航栏选择市场 > 应用市场。
- 在应用市场页面通过关键字搜索 ack-arms-cmonitor 组件，然后单击 ack-arms-cmonitor。
- 在 ack-arms-cmonitor 页面单击右上角的一键部署。
- 在创建面板中，选择目标集群，然后单击下一步。说明命名空间默认为 arms-prom。
- 单击确定。
- 在左侧导航栏单击集群，然后单击刚刚安装了 ack-arms-cmonitor 组件的集群名称。
- 在左侧导航栏选择工作负载 > 守护进程集，在页面顶部选择命名空间为 arms-prom。
- 单击 otel-collector-service。查看 otel-collector-service（Service）是否正常运行，如下图所示对外暴露了多种 Receivers 端口接收 OpenTelemetry 数据，则表示安装成功。
转载自 从Opentracing、OpenCensus 到 OpenTelemetry，看可观测数据标准演进史 - 知乎 (zhihu.com)