Open JasmineJ1230 opened 3 years ago
基于近期对于上云和监控数据管理的需求，对Open Telemetry做了一些调研工作，并对部分功能做了操作实验。以下为结果总结。
（Open Telemetry以及对应的AWS Distribution都提供了相当多的demo和文档说明，故在此不再赘述该工具的使用方法，文档链接见文末）
可观察性是保证应用质量和稳定性的一项重要能力。而不同的可观测性产品（如Jaeger、Prometheus等）有各自的数据采集和管理方式，导致应用接入后，可移植性降低。
Open Telemetry主要解决的，就是数据采集和传送的规范问题。
接入Open Telemetry Api后，只需通过配置（sdk初始化代码/配置文件/系统变量/环境变量），就可将同一份监控数据发送到多个对应的可观测性服务，进行分析和展示。将应用的更改最小化。这点与capa的设计初衷是相符的。
Open Telemetry的数据模型主要分为Trace、Metrics、Log三种不同类型的监控数据，通过上下文进行关联。数据模型和API的定义是比较合理且完备的。 目前Trace和Metrics的模型定义都已进入稳定阶段。logs相关仍在设计中。 具体定义见 https://github.com/open-telemetry/opentelemetry-proto
OpenTelemetry依照统一的契约，提供了不同语言的SDK实现。 但目前SDK仍在不断建设和迭代的过程中，发版比较频繁。
各主要功能的SDK建设情况如下：
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 支持的框架见。
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和实验如下：
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做了一些调研工作，并对部分功能做了操作实验。以下为结果总结。
（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建设情况如下：
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和实验如下：
四、优点
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为稳定可用状态。 且迭代频繁，变数大。如果接入大量应用，前期稳定性可能会受到影响。
六、相关文档