[Disccusion] Open Telemetry调研

[JasmineJ1230]

基于近期对于上云和监控数据管理的需求，对Open Telemetry做了一些调研工作，并对部分功能做了操作实验。以下为结果总结。

（Open Telemetry以及对应的AWS Distribution都提供了相当多的demo和文档说明，故在此不再赘述该工具的使用方法，文档链接见文末）

一、Open Telemetry的目的

可观察性是保证应用质量和稳定性的一项重要能力。而不同的可观测性产品（如Jaeger、Prometheus等）有各自的数据采集和管理方式，导致应用接入后，可移植性降低。

Open Telemetry主要解决的，就是数据采集和传送的规范问题。

接入Open Telemetry Api后，只需通过配置（sdk初始化代码/配置文件/系统变量/环境变量），就可将同一份监控数据发送到多个对应的可观测性服务，进行分析和展示。将应用的更改最小化。这点与capa的设计初衷是相符的。

二、Open Telemetry做了什么

1. 为可观测领域提供标准化的数据模型和API定义

Open Telemetry的数据模型主要分为Trace、Metrics、Log三种不同类型的监控数据，通过上下文进行关联。数据模型和API的定义是比较合理且完备的。
目前Trace和Metrics的模型定义都已进入稳定阶段。logs相关仍在设计中。
具体定义见 https://github.com/open-telemetry/opentelemetry-proto

2. 提供多语言SDK实现（Go、Java、JS、Python……）

OpenTelemetry依照统一的契约，提供了不同语言的SDK实现。
但目前SDK仍在不断建设和迭代的过程中，发版比较频繁。

各主要功能的SDK建设情况如下：

• Trace功能的SDK都已基本稳定
• Metrics功能SDK仍在alpha测试中，目前并未正式在sdk中提供，需要另外添加依赖使用。
  按项目发展计划，将在 2021.11.30 提供稳定版本。详见 https://github.com/open-telemetry/opentelemetry-specification/milestones
• Log功能API和SDK都尚未完成

3. 提供多种主流框架的自动埋点，可实现无代码侵入的应用监控

Open Telemetry支持人工埋点和自动埋点两种方式。且两种方式不会互相影响。

• 人工埋点：即开发时显式地在代码中调用OpenTelemetry的API，记录自定义的监控数据。API使用方式见 https://opentelemetry.io/docs/java/manual_instrumentation/

• 自动埋点：部分语言（比如Java）支持通过字节码注入的方式，对主流框架进行无代码侵入的自动埋点。
  使用方式非常简单（甚至不需要依赖api/sdk），只需要下载Open Telemetry提供的javaagent jar包，并在应用启动时添加JVM参数。agent配置同样通过JVM参数实现。
  使用手册见 https://github.com/open-telemetry/opentelemetry-java-instrumentation#getting-started
  支持的框架见。

4. 多种数据发送方式，可将监控数据发送至不同可观测性后端

Open Telemetry的数据发送主要有两种方式，一是直接发送，二是通过otel协议将数据发送至单独部署的collector做中转，再发送至可观测性后端。

• 直接发送
  不经过中转，应用利用SDK中的Exporter实现，直接将数据发送到对应的可观测服务。
  SDK中对Jaeger、Zipkin、Prometheus等提供了完备的Exporter支持，数据可通过配置直接导入这些服务。
  用户也可自行实现Exporter接口，将数据导入自己的数据分析服务。

• Data Collector
  Open Telemetry利用Data Collector 实现了 数据收集传输 与 应用代码 的进一步解耦。
  Data Collector是一个独立运行的进程实例（可以独立部署成服务，或集成在sidecar中）。应用通过SDK中默认提供的OTLP Exporter，将监控数据 以OTLP协议规定的格式，通过 http/gRPC 发送到Data Collector，Data Collector进行处理后，发送到配置的可观测性服务。
  Data Collector在架构设计上 分为 Receiver、Processor、Exporter三部分。通过配置文件中定义的pipeline来构建整个监控数据的处理流程。用户可自定义数据的处理规则和发送目标，也可以调整每个组件的配置参数。
  

不管使用哪一种发送方式，数据发送的目的地都是可多选的（Exporter可配置多个），即同一份监控数据，可以同时发给多个不同的可观测性服务。
这样做的直接优势是，数据处理和导出逻辑的实现与语言无关。在各可观测性服务为Open Telemetry贡献实现时，可以统一使用Go语言开发（https://github.com/open-telemetry/opentelemetry-collector-contrib） ，不再被用户的应用程序使用的语言所限制。

三、实验情况

调研过程耗时约5人日，总共完成demo和实验如下：

1. 以手动埋点方式，向本地输出Trace日志。
2. 同时使用手动埋点和自动埋点，为已有soa服务添加Trace监控。并通过自定义Exporter，将日志发送到Clog。
3. 利用Open Telemetry的示例程序，以Docker方式本地部署Data Collector，发送日志到Jaeger、Zipkin、Prometheus。
4. AWS Lambda编写Java程序（只允许Java11），使用Open Telemetry埋点，以java agent方式部署，并发送Trace日志到X-ray和CloudWatch。
5. 利用AWS Distro for OpenTelemetry示例程序，使用AWS ECS部署Data Collector和应用，收集应用日志并输出到CloudWatch。
   
   
   

四、优点

Open Telemetry主要优势有三方面。

一是代码改动小。接入API后，基本可以做到用同一套代码切换不同的可观测性后端服务。对于日志自定义要求比较低的Java应用，甚至可以做到无代码侵入的监控。

二是耦合度低，可扩展性强。得益于合理的模型设计，项目各组件耦合度不高，即使SDK中没有需要的组件，用户也可通过自定义实现。

三是认可度高。项目目前活力和生命力很强，迭代速度很快。且其在Google、AWS等主流云厂商中认可度是非常高的。
AWS为其贡献了整套Distribution（AWS Distro for OpenTelemetry），并跟随主项目的进展不断迭代。可用于部署在Lambda, EC2，ECS，EKS，Fargate上的程序程序，且工具本身不收取费用。在遵循Open Telemetry规范，支持已有功能的情况下，也能自动对AWS相关SDK进行埋点监控。
其他云厂商和可观测性服务也积极为其贡献组件支持，实现情况见 https://opentelemetry.io/registry/

五、不足

最大的问题是目前项目整体仍处在开发阶段，功能支持并不完全。目前仅Trace为稳定可用状态。
且迭代频繁，变数大。如果接入大量应用，前期稳定性可能会受到影响。

六、相关文档

• Open Telemetry官方文档：https://opentelemetry.io/docs/concepts
• Open Telemetry项目地址：https://github.com/open-telemetry
• java应用自动监控功能文档：https://github.com/open-telemetry/opentelemetry-java-instrumentation#getting-started
• Open Telemetry milestone（未发布功能的上线时间计划）：https://github.com/open-telemetry/opentelemetry-specification/milestones
• 支持组件查询：https://opentelemetry.io/registry
• AWS Distro for OpenTelemetry文档：https://aws-otel.github.io/docs/introduction