在介绍框架的监控告警之前，我们离不开业内可观测性的标准介绍， OpenTelemetry 关于监控告警这块的设计，以及相关规范。 OpenTelemetry 在这块的内容也比较多，我们选择一些重点来介绍一下。

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