什么是OpenTelemetry？

前言

        关于OpenTelemetry是什么和不是什么的简短解释。

        微服务体系结构使开发人员能够更快、更独立地构建和发布软件，因为他们不再受制于与单体应用相关的复杂发布过程。 

        随着这些现在分布式系统的扩展，开发人员越来越难以了解他们自己的服务如何依赖或影响其他服务，尤其是在部署之后或中断期间，速度和准确性至关重要。

        可观察性使开发人员和运维人员都可以了解他们的系统。

是什么？

        为了让系统都是可观测必须让它仪表化，也就是说，代码必须发出跟踪、指标和日志。然后必须将检测数据发送到可观察性后端工具，有许多可观察性后端工具，从自托管开源工具（例如 Jaeger 和 Zipkin）到商业 SaaS 产品。

        以前，代码仪表器化的方式会有所不同，因为每个可观察性后端都有自己的三方库和agent，用于将数据发送到可观察性后端工具。

        这意味着没有用于将数据发送到可观察性后端的标准化数据格式，此外，如果一家公司选择切换可观测性后端工具，这意味着他们将不得不重新修改他们的代码并配置新代理，以便能够将可观测数据发送到新选择的工具(由于缺乏标准化，最终结果是缺乏数据可移植性和增加用户维护可观测库的负担)。

        认识到标准化的必要性后，云社区聚集在一起，诞生了两个开源项目：OpenTracing（云原生计算基金会 (CNCF) 项目）和 OpenCensus（Google 开源社区项目）。

OpenTracing 提供了供应商中立的 API，用于将可观测数据发送到可观察性后端；但是，它依赖于开发人员实现自己的库来满足规范。

OpenCensus 提供了一组特定于开发语言的库，开发人员可以使用这些开发库来发送系统的可观测数据到他们支持的任何一个后端。

你好, OpenTelemetry!

        为了拥有一个单一的标准，OpenCensus 和 OpenTracing 于 2019 年 5 月合并形成了 OpenTelemetry（简称 OTel）。作为 CNCF 孵化项目，OpenTelemetry 充分利用了两个工具的优点，并且还做了一些扩展。

        OTel 的目标是提供一组标准化的与供应商无关的 SDK、API 和工具，用于摄取、转换数据并将数据发送到可观察性后端（即开源或商业供应商）。

OpenTelemetry 可以为我做什么？

        OTel 拥有来自云提供商、供应商的用户，并最终得到广泛行业支持和采用。它能为你提供：

• 每种语言都有一个独立于供应商的三方库，支持自动和手动仪表

• 可以以多种方式部署的独立于供应商的收集器工具库

• 一套完整的端到端的生成、发送、收集和导出可观测数据的实现

• 可以完全控制您的数据，能够通过配置将数据并行发送到多个目的地

• 开放标准的语义约定以确保能够提供与供应商无关的数据收集

• 能够并行支持多种上下文传播格式，以协助随着标准的发展进行迁移

• 无论您在可观察性之旅的哪个阶段，都有一条前进的道路

        由于支持各种开源和商业协议、格式和上下文传播机制以及为 OpenTracing 和 OpenCensus 项目做了兼容，因此很容易采用 OpenTelemetry。

OpenTelemetry 不是什么？

        OpenTelemetry 不是像 Jaeger 或 Prometheus 那样的可观察性后端，相反，它支持将可观测数据导出到各种开源和商业后端。它提供了一个可插拔的插件化架构，因此可以轻松添加额外的技术协议和格式。

下一章是什么？

• 开始OTel

• 了解 OpenTelemetry 的概念