Skip to main content

OpenTelemetry入门-概念

1. 什么是OpenTelemetry​

微服务架构使开发人员能够更快地构建和发布软件，同时具有更大的独立性，因为他们不再受制于与单体架构相关的繁琐发布流程。随着这些现在分布式的系统的规模扩大，开发人员越来越难以看到他们自己的服务如何依赖或影响其他服务，特别是在部署期间或停机期间，速度和准确性至关重要。观测性使开发人员和操作员都能够获得对其系统的可见性。

那么呢？为了使系统具有可观测性，必须进行仪表化。也就是说，代码必须发出跟踪、度量和日志。然后，仪表化数据必须发送到观测性后端。市场上有许多观测性后端，从自托管的开源工具（例如Jaeger和Zipkin）到商业SaaS产品不一而足。

过去，代码的仪表化方式会有所不同，因为每个观测性后端都有自己的仪表化库和代理程序，用于向工具发出数据。这意味着没有标准化的数据格式用于将数据发送到观测性后端。此外，如果公司选择切换观测性后端，这意味着他们必须重新仪表化他们的代码并配置新代理程序，以便能够向新的工具发出遥测数据。

缺乏标准化的结果是数据可移植性的缺乏和用户维护仪表化库的负担。认识到标准化的必要性，云社区走到了一起，诞生了两个开源项目：OpenTracing（一个Cloud Native Computing Foundation（CNCF）项目）和OpenCensus（一个Google开源社区项目）。

OpenTracing 提供了一个供应商中立的API，用于将遥测数据发送到观测性后端；但是，它依赖于开发人员实现自己的库以符合规范。

OpenCensus 提供了一组特定语言的库，开发人员可以使用这些库来仪表化他们的代码，并将其发送到他们支持的任何一个后端。

由于上面说的种种原因就催生了OpenTelemetry，

为了拥有一个单一的标准，OpenCensus和OpenTracing于2019年5月合并，形成了OpenTelemetry（简称OTel）。作为CNCF孵化项目，OpenTelemetry结合了两者的优点，并有所创新。OTel的目标是提供一组标准化的供应商中立的SDK、API和工具，用于将数据摄入、转换和发送到观测性后端（即开源或商业供应商）。

2. 基于OpenTelemetry我们能做什么​

  • 每种语言一个供应商中立的仪器库，支持自动和手动仪器化。
  • 一个供应商中立的收集器二进制文件，可通过多种方式部署。
  • 端到端实现，用于生成、发出、收集、处理和导出遥测数据。
  • 通过配置并行发送数据到多个目的地的完全控制权。
  • 开放的标准语义约定，确保供应商中立的数据收集。
  • 支持多个上下文传播格式并行使用，以协助随着标准的发展而进行迁移。
  • 不管您的观测旅程处于何种阶段，都有前进的道路。
  • 支持各种开源和商业协议、格式和上下文传播机制，并为OpenTracing和OpenCensus项目提供了桥接，因此采用OpenTelemetry非常容易。