HTTP请求时长指标用秒还是毫秒？Prometheus与OpenTelemetry标准分歧咨询

分歧现状 #

OpenTelemetry的HTTP指标语义规范要求HTTP请求时长使用毫秒作为单位；而Prometheus的指标命名实践指南中，推荐时长类指标使用秒作为基准单位。

实际项目中不同工具基于自身生态做出了不同选择：

• Pyrra（面向Prometheus生态的SLO工具）仅支持秒级时长，以Prometheus指南为依据
• Istio遵循OpenTelemetry标准，仅输出毫秒级的HTTP请求时长指标

分歧是否会得到解决？ #

短期来看两者规范很难完全统一：

• OpenTelemetry的语义规范旨在实现跨厂商、跨系统的全链路观测统一标准，毫秒精度更适配分布式链路追踪的场景需求
• Prometheus的命名规范是其生态长期实践形成的共识，秒作为国际单位制基准单位，在监控告警配置和可读性上更符合传统监控习惯

不过OpenTelemetry社区一直在推进与其他监控生态的兼容协调，未来不排除通过规范补充、兼容层设计等方式减少这类冲突，但目前没有明确的统一时间表。

项目应当遵循哪一项标准？ #

需根据项目定位和所处生态决定：

• 若项目完全属于Prometheus生态（如仅用于Prometheus监控告警、SLO管理），遵循Prometheus的秒级标准更适配，能降低生态内的适配成本
• 若项目基于OpenTelemetry构建，或需要与全链路观测系统（如Jaeger、Zipkin）集成，优先遵循OpenTelemetry的毫秒标准，保证跨系统的数据一致性
• 对于跨生态的项目，建议提供单位转换选项，或在指标中明确标注单位（如http_request_duration_ms/http_request_duration_seconds），避免歧义

Pyrra优先采用Prometheus标准是否“不正确”？ #

这不能算“不正确”。Pyrra的核心受众是Prometheus生态用户，适配自身生态规范能更好融入现有工作流，降低用户学习和适配成本。只要项目在文档中明确说明指标单位要求，就是合理的设计选择。

如何向OpenTelemetry反馈该问题？ #

可通过以下途径反馈：

• 参与OpenTelemetry的Metrics SIG（Special Interest Group）讨论，该工作组负责指标语义规范的制定和生态协调
• 在OpenTelemetry规范仓库的Issue区提交相关讨论，提出跨生态兼容的需求

上游层面解决的可能性 #

短期两边生态会继续维持现有规范，但长期可期待：

• OpenTelemetry规范补充对Prometheus生态的兼容说明，比如允许可选的秒级指标输出
• Prometheus生态对带明确单位的指标（如毫秒级）提供更好的支持
• 第三方工具（如指标网关、转换组件）提供更便捷的单位转换能力

你当前通过记录规则转换单位的方案，是跨生态适配的合理临时方案。

内容的提问来源于stack exchange，提问作者modulitos