[Discussion] Metric Api Design with Open Telemetry

[JasmineJ1230]

一、设计目标

监控相关日志类型主要有 Trace、Metrics、Logs 三种，即 调用链追踪、数据指标、文本日志。
具体说明可参考 OpenTelemetry - Data sources。

结合Capa整体的设计目标，我们需要 为 以上三种类型日志的提供通用API和SDK。下层实现根据环境不同自动切换，将日志数据发往不同的监控服务。

二、API方案调研

监控方面，业界普遍认可的方案是 Open Telemetry 的设计。Open Telemetry为以上三种日志类型提供统一的API，以及多语言的SDK实现。可通过 直接发送 / side car 的方式发送采集的日志数据。可利用其SDK自身提供的导出逻辑实现，也可自定义开发导出逻辑，将数据发送到需要的监控服务。

前期调研的基本情况可见 Open Telemetry调研。
使用效果见 Demo 演示。

Capa的设计目标与Open Telemetry是契合的。考虑到工作量和日后在各个平台上的兼容性，我们可以尽可能复用其API和SDK，在需要的地方做一些封装和扩展。

Trace 和 Metrics 的API，Open Telemetry已有稳定版本，考虑到未来发展和兼容性，建议在API层尽量少做修改，使用其已有规范进行开发。

Logs API仍在设计中。而目前在实际开发中，最常使用的Log4j2。建议Java可先基于Log4j2按需开发自定义Appenders，满足当前的日志记录需求。

三、基于现实上云需求的调研 和 开发工作评估

Capa目前仅集中在应用层面的日志数据采集，即 开发者的业务逻辑埋点 和 其他中间件内部埋点。
为满足上云需求，对于以上三种日志类型，初期我们计划使用的监控服务 以及 需要的coding工作 如下：

日志类型	AWS监控服务	开发工作	Ctrip监控服务	开发工作
Trace & Metrics	/	Data Collector模式 - 配置 / SDK 模式 - Pipeline构建	/	SDK 模式 - Pipeline构建
Trace	X-Ray	Data Collector模式 - 额外部署 / SDK 模式 - Exporter	Cat Transaction	SDK 模式 - Exporter
Metrics	Cloud Watch	Data Collector模式 - 额外部署 / SDK 模式 - Exporter	Hickwall	SDK 模式 - Exporter
Logs	Cloud Watch Logs（暂定）	log4j2 自定义Appender	Clog	log4j2 自定义Appender

对于在Ctrip的监控，我们需要关注的埋点内容主要是业务逻辑埋点。可以采用SDK直接导出的方式，我们需要自己实现 所有的数据导出逻辑（Exporter）。

对于在AWS的监控，数据采集方面，AWS基于Open Telemetry提供了一些扩展功能，可采用手动埋点或者agent自动埋点（字节码注入）的方式，对AWS的SDK自动埋点。操作方式

数据导出方面，开发量取决于我们选择的方案。

部署方式	优点	缺点
SDK直接导出	逻辑透明，且资源消耗相对小	需要开发所有的数据导出逻辑
Data Collector	无额外开发量	需要以Sidecar或独立服务的方式另外部署，与Capa最初的设计目标不完全相符，且逻辑相对黑盒

基于使用的灵活性，建议采用SDK的方式开发。

四、相关文档

• 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