作者:Reiley Yang
在 OpenTelemetry 规范 v1.0 发布之后,我们现在把更多的精力放在了指标规范上。以下是我们到目前为止所取得的进展,以及接下来几个月将要完成的事情。
鉴于目前存在许多成熟的指标解决方案,理解 OpenTelemetry 的指标目标是很重要的:
能够将指标与其他信号连接起来。 例如,指标和追踪可以通过范例相关联,而指标维度可以通过 Baggage 和 Context 来丰富。此外,Resource 可以以一致的方式应用到日志/指标/追踪。
为 OpenCensus 客户迁移到 OpenTelemetry 提供了一条路径。 这就是 OpenTelemetry 的最初目标——OpenCensus 和 OpenTracing 的融合。我们将着重于提供语义和功能,而不是对 API 进行 1-1 的映射。
使用现有的指标工具标准。 最小的目标是为 Prometheus 和 StatsD 提供全面支持——用户应该能够使用 OpenTelemetry 客户端和 Collector 来收集和导出指标,并能够实现与原生客户端相同的功能。
为了加速指标的工作,我们有三个并行运行的工作流:
现在: 我们正在采用一种迭代的方法,包含几个小的里程碑。目前有一小部分语言客户端(.NET、Java、Python)正在与我们密切合作开发原型[2]。如果你有兴趣参与或提供需求/建议,请联系并在 CNCF Slack 上的otel-metrics 频道[3](点击这里[4]首次加入 CNCF 工作区)说 hi。
2021 年 3 月 31 日: 使指标数据模型和协议(OTLP)“稳定”。这意味着人们可以使用 OTLP 作为指标的交换格式。
2021 年 5 月 31 日: 发布一个“实验性的”指标 API/SDK 规范,我们可以推荐给语言客户端所有者来实现指标预览版。这意味着从 2021 年 6 月 1 日开始,我们会向客户端维护者推荐实施。稍后我们可能会引入额外的特性,但我们会提高标准,以避免在这个阶段改变/增加范围。
2021 年 5 月 31 日: 完成第一阶段在 OpenTelemetry 收集器中完全支持 Prometheus 的所有项目,以确保规范和实现的稳定性。Prometheus 接收器和远程书写输出器在这个阶段将功能齐全。
2021 年 9 月 30 日: Metrics API/SDK 规范达到“特性冻结”。这意味着从 2021 年 10 月 1 日开始,我们将专注于 bug 修复或编辑更改。根据实际进展,API 规范可能比 SDK 更早达到特性冻结。
2021 年 11 月 30 日: Metrics API/SDK 规范达到“稳定”。与规范的稳定版本一起,我们应该期待来自多种语言客户端的候选版本,这与我们所拥有的追踪类似。根据实际进展,API 规范可能比 SDK 更早达到稳定。
注意:每个里程碑都依赖于它之前的里程碑,包括两个工作流之间的相互依赖,因此一个里程碑中的滑移可能会导致所有后续里程碑的滑移。每个工作流都将尽早明确地指出风险,从而给 OpenTelemetry 社区一个机会来减轻进度影响。
这些工作流的最新时间表可以在 GitHub 上的OpenTelemetry 项目[5]中找到。
当前的时间线基于当前项目维护者和贡献者的可用性。如果有更多的工程资源和项目参与,这些时间表可以加快。如果你是一个项目或工作流的干系人,并且有兴趣增加工程资源来帮助加快进度,请与我(@reyang)或 Alolita (@alolita)联系。
[1]
这里: https://github.com/open-telemetry/wg-prometheus/projects/1
[2]
原型: https://github.com/open-telemetry/oteps/pull/146
[3]
otel-metrics 频道: https://cloud-native.slack.com/archives/C01NP3BV26R
[4]
这里: https://slack.cncf.io/
[5]
OpenTelemetry 项目: https://github.com/orgs/open-telemetry/projects