开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第14天，点击查看活动详情
引言
上一节介绍了时至今日为什么系统的可观测性建设越来越重要，日志、链路、指标是系统可观性建设的数据基础。通过 OpenTelemetry Demo 运行对系统可观性展现的形态有了大致的了解。
今天从一个开发的视角来介绍 OpenTelemetry，通过 OpenTelemetry API 自动提交系统遥测数据，来建设系统的可观性。
可观测性使开发人员和运维人员都可以获得对其系统的可见性。
什么是 OpenTelemetry?
Background information
微服务架构使开发人员能够更快地构建和发布软件，并且具有更大的独立性，因为他们不再受制于与单体架构相关的复杂发布过程。随着这些现在分布式系统的扩展，开发人员越来越难以了解自己的服务如何依赖或影响其他服务，尤其是线上环境更新后或者当遇到线上问题时，研发人员需要快速和准确的观测线上环境的状态以及快速定位解决生产问题。
So what?
为了使系统可观察，我们通过代码输出日志、服务链路、指标信息等观测系统的数据。然后，这些数据发送到处理对应数据的后台服务，如日志文件通过 filebeat 解析后入到 ES 中进行查询，服务链路数据通过 skywalking 采集入到 ES 中查询展示，指标信息通过 prometheus 采集通过 Grafana 进行展示。而像刚刚提到的开源中间件还有很多，如 Jaeger，Zipkin。因为每个观测中间件后端都有自己的检测库和代理，采集数据格式和方式也各不相同。
这意味着没有标准化的数据格式将数据发送到可观测性后端。此外，如果一家公司选择切换可观测性后端，这意味着他们必须重新检测其代码并配置新的代理，以便能够将遥测数据发送到所选的新工具。
由于缺乏标准化,数据可移植性较差并且开发维护成本高
认识到标准化的必要性，云社区走到了一起，诞生了两个开源项目：OpenTracing（Cloud Native Computing Foundation(CNCF) 项目）和 OpenCensus（Google Open Source 社区项目）
- OpenTracing 提供了一个中立的 API，用于将遥测数据发送到可观测性后端；但是，它依赖于开发人员自己实现来满足规范。
- OpenCensus 提供了一组特定于语言的库，开发人员可以使用它来检测他们的代码并发送到他们支持的任何一个后端。
Hello, OpenTelemetry!
为了拥有一个单一的标准，OpenCensus 和 OpenTracing 于2019年5月合并为 OpenTelemetry（简称 OTel）。作为 CNCF 的一个孵化项目，OpenTelemetry 融合了各自优势形成了一个最佳实践。
OTel 的目标是提供一组标准化的与供应商无关的 SDK，API 和 工具，用于获取，转换数据并将其发送到可观测性后端（即开源或商业供应商）。
OpenTelemetry 能做什么？
OTel 拥有广泛的行业支持并有云提供商，供应商和终端用户使用。它提供：
- 为每种语言提供了与供应商无关的单一检测库，支持手动和自动检测
- 可通过多种方式部署的与供应商无关的单个中立收集器二进制文件
- 用于生成、发出、收集、处理和导出遥测数据的端到端实现
- 完全控制您的数据，能够通过配置将数据并行发送到多个目标
- 开放标准语义约定，确保与供应商无关的数据收集
- 能够并行支持多种上下文传播格式，以帮助随着标准的发展进行迁移
- 无论您处于可观测性之旅的哪个阶段，都是一条前进的道路
通过支持各种开源和商业协议，格式和上下文传播机制，以及为 OpenTracing 和 OpenCensus 项目提供垫片，采用OpenTelemetry 很容易。
OpenTelemetry 不能做什么
OpenTelemetry 不是像 Jaeger 或 Prometheus 那样的可观测性后端。相反，它支持将数据导出到各种开源和商业后端。它提供了一个可插拔的架构，因此可以轻松添加其他技术协议和格式。
