OpenTelemetry 的好处
收集应用数据并不是什么新鲜事。但是，从一个应用到另一个应用，收集机制和格式很少是一致的。这种不一致，对于只是试图了解应用健康状况的开发人员和 SRE 来说，可能是一场噩梦。
OTel 为向云原生应用添加可观测能力工具提供了事实上的标准。这意味着公司不需要花费宝贵的时间来开发收集关键应用数据的机制，而是可以花更多的时间来交付新功能。
这类似于 Kubernetes 如何成为容器编排的标准。它的广泛应用使组织更容易实施容器部署，因为他们不需要构建自己的企业级调度平台。使用Kubernetes进行模拟演示，很容易看到它为整个行业带来的好处。
OpenTracing 和 OpenCensus 发生了什么变化？
OpenTracing 在 2016 年成为 CNCF 项目，其目标是为分布式跟踪提供与供应商无关的规范，使开发人员能够通过检测他们的代码从头到尾跟踪请求。然后，谷歌在 2018 年将 OpenCensus 作为开源项目。这是基于谷歌的统计库，该库在内部用于从其分布式系统收集跟踪和指标。与 OpenTracing 项目一样，OpenCensus 的目标是为开发人员提供一个与供应商无关的库，用于收集跟踪和指标。
这导致了两个相互竞争的跟踪框架，也是人们口头说的“跟踪战争”。通常，竞争对最终用户来说是一件好事，因为它孕育了创新。然而，在开源规范世界中，竞争可能导致应用、贡献和支持不佳。
回到 Kubernetes 的例子，想象一下如果每个人都使用不同的调度解决方案，容器的采用会更加脱节和缓慢。为避免这种情况，在巴塞罗那举行的 KubeCon 2019 上宣布 OpenTracing 和 OpenCensus 项目将合并为一个名为 OpenTelemetry 的项目并加入 CNCF。
第一个 beta 版本于 2020 年 3 月发布，它仍然是继 Kubernetes 之后第二活跃的 CNCF 项目。
OpenTelemetry远程监测组件
OTel 由几个不同的组件组成，如下图所示。让我们从左到右从高层次看一下每一个组件：
API
这些是核心组件并且与语言（例如 Java、Python、.Net 等）相关。API 为您的应用提供了基本的“开发途径”。
SDK
这也是一个与语言相关的组件，是提供 API 和导出器之间桥梁的中间人。SDK 允许进行额外的配置，例如请求过滤和事务采样。
过程导出器
这允许您配置要将其发送到哪个后端。导出器将检测部分与后端配置分离。这使得切换后端变得容易，而无需重新检测代码。
收集器
收集器接收、处理和导出远程监测数据。虽然在技术上不是必需的，但它是 OpenTelemetry 架构的一个非常有用的组件，因为它允许后端更灵活接收和发送应用的远程监测数据。
收集器有两种部署模型：
与应用驻留在同一主机上的代理（例如，二进制、DaemonSet、sidecar 等）
与应用完全分离的独立进程
由于收集器只是收集和发送远程监测的规范，因此它仍然需要一个后端来接收和存储数据。