OpenTelemetry

相关组件

我们来看一张OpenTelemetry组件的关系图，在OpenTelemetry Metrics标准的实现中，主要包含以下组件。

在标准化文档的落地时，各个组件通常都是采用接口化设计，以提高可扩展性：

Meter Provider

用于接口化管理全局的Meter创建，相当于全局的监控指标管理工厂。

Meter

用于接口化创建并管理全局的Instrument，不同的Meter可以看做是不同的程序组件。例如框架中的各个组件可以看做是不同的Meter，比如gclient和ghttp就是两个不同的Meter。

Instrument

用于管理不同组件下的各个不同类型的指标，例如在ghttp下，就会有http.server.request.duration、http.server.request.body_size等指标。

Measurements

对应指标上报的具体的DataPoint指标数据，是一系列的数值项。

View

实现对Measurements的计算、汇总、过滤、修改等操作，通常指标都是数值类型，所以这个通常都使用默认的View即可。

Metric Reader

用于实现对指标的数据流读取，内部定义了具体操作指标的数据结构。OpenTelemetry官方社区提供了多种灵活的Reader实现，例如PeridRader、ManualReader等。

Metric Exporter

Exporter用于暴露本地指标到对应的第三方厂商，定义了具体是push还是pull的数据传输方式。Exporter需要用到Reader，其中Reader只有几种方式，但是Exporter会根据厂商而定，会有很多，例如：promtheus、zipkin等。

一个Instrument多个DataPoint的数据流如下图所示：

相关类型

OpenTelemetry的社区实现为了满足不同的使用场景，因此类型的设计粒度比较细，分为int64和float64数据类型，并且包含同步和异步指标类型。

同步类型

同步类型用于快速暴露监控指标，无论metrics reader是否使用该监控指标，指标的计算结果已完成，待读取使用。例如，HTTP的请求总数、请求大小，这些数值必须在请求执行流程中记录到对应的监控指标数值中，适合作为同步指标来管理。

异步类型

异步类型的监控指标只有在metrics reader开始使用该监控指标时才会执行指标计算逻辑。异步类型的监控指标需要设置一个回调函数，该回调函数用于生成指标数值，并在metrics reader读取指标时才会触发回调函数。例如，机器CPU、内存、磁盘使用量的指标，如果没有目标端拉取或者使用该指标时，提前计算指标值毫无意义且浪费计算资源，适合作为异步指标来管理。

框架监控组件

组件抽象

框架通过gmetric组件来实现监控能力，gmetric组件内部设计的组件层级关系同OpenTelemetry Metrics类似：

gmetric组件使用了抽象解耦设计，一方面是因为框架设计需要减少外部依赖；另一方面是为了实现监控的自动开关能力。组件默认情况下使用了NoopPerform的实现对象，在默认情况下监控能力是关闭的，只有在真正引入监控接口实现时才会自动开启监控能力。

指标类型

框架提供的指标类型相比较OpenTelmetry社区实现去掉了int64数值类型，而是使用了统一的float64数值类型以简化使用。但同时需要注意，开发者在设计指标数值时尽可能避免小数设计，以避免数值计算的精度问题。特别是在Histogram类型的Buckets设计时，不建议使用小数。

同步类型

异步类型 

参考资料

• https://github.com/prometheus/client_golang

• https://github.com/open-telemetry/opentelemetry-go-contrib

• https://opentelemetry.io/docs/specs/otel/metrics/api/

• https://opentelemetry.io/docs/specs/otel/metrics/data-model