在监控系统中为 HTTP 服务命名吞吐指标时，一个看似微小的选择 —— 使用 Hz 还是 rps（requests per second）—— 实际上反映了工程师对度量本质的理解深度。本文从度量衡的基本定义出发，阐明为何 HTTP 请求性能指标应避免使用 Hz 单位，并给出可落地的命名规范与实践参数。
周期性事件与非周期性事件的度量差异
赫兹（Hz）是国际单位制中频率的标准单位，定义为每秒完成的周期性循环次数。从物理学到电子工程，Hz 始终用于描述具有固定周期的重复现象：电磁波的振荡频率、时钟信号的脉冲速率、声音波的振动次数。这些共同特征是事件之间存在恒定的时间间隔，且理论上可以无限精确地预测下一次事件发生的时间。
HTTP 请求则截然不同。用户在浏览器中的一次点击、一次 API 调用、一次文件下载，这些请求的到达时间不具备任何固定规律。在高并发系统中，请求到达是典型的泊松过程或非平稳随机过程，其时间间隔服从指数分布或其他复杂分布，根本不存在 “周期” 这一概念。将用于描述周期性信号的 Hz 用于描述这种非周期性离散事件，在度量衡的层面上是根本性的概念混淆。
监控系统中的单位滥用现象
在实际工程中，这种混淆并不罕见。部分监控系统或文档中出现了类似「服务器处理能力为 1000Hz」或「QPS (Queries per Second) 达到 500Hz」的表述，这种写法的问题在于它将吞吐量这一计数率与周期性频率混为一谈。当工程师阅读监控仪表盘时，Hz 会潜意识地暗示系统存在某种固定频率的脉冲机制，这与 HTTP 请求的真实处理模型完全不符。
正确做法是使用请求速率的单位，即每秒请求数（requests per second, rps）或简写为 req/s。这一单位明确表达了「在单位时间内累计的离散事件数量」这一含义，与 HTTP 请求的非周期性本质完美契合。在大多数中文技术文档中，RPS 已成为约定俗成的术语，而在英文文档中则常用 requests/sec 或 req/s 表示。
来自 OpenTelemetry 的语义约定
在可观测性领域，OpenTelemetry 的 HTTP 指标语义约定明确推荐使用 rate-based 的计量方式。其规范中将 HTTP 服务器的请求计数与每秒速率分开定义：计量名称通常为 http.server.request.count，配合 per_second 的聚合方式得到每秒请求数。这一约定本质上否认了 Hz 在 HTTP 吞吐指标中的适用性，因为 Hz 暗示的是事件本身的固有频率属性，而非累计计数的时间导数。
采用标准化语义约定的另一个实际好处在于告警规则的兼容性。当监控系统期望接收的是 rps 而非 Hz 时，使用 Hz 命名的指标将导致告警阈值无法正确映射 —— 因为两者的量纲含义完全不同。这种不一致会在多团队协作或系统迁移时造成额外的认知负担和配置错误。
工程实践中的命名清单
在实际项目中，建议采用以下命名规范来定义 HTTP 吞吐指标：
计量类型应使用 Counter（累加计数器），而非 Gauge（瞬时值）或 Histogram（直方图），因为请求数量只增不减，需通过时间导数转换为速率。计量名称推荐使用 http.server.requests.total 或 http.server.request.count，明确表达请求总数。聚合方式在 Prometheus 或类似时序数据库中应使用 rate () 或 irate () 函数计算每秒速率，而非直接展示计数值。展示单位必须标注为 req/s 或 rps，避免使用 Hz、s^-1 或任何暗示周期性的表述。对于不同端点或方法的细分，可通过 label（如 http.method、http.route）进行维度切分，而非创建独立的 Hz 指标。
结论
HTTP 请求作为非周期性离散事件，其吞吐率的正确度量方式是每秒请求数（RPS 或 req/s），而非用于周期性信号的赫兹（Hz）。这种区分并非仅仅是命名习惯问题，而是关乎度量衡的本质定义与团队协作时的认知一致性。在监控系统日趋复杂的今天，遵循这一约定将使指标更具可读性、更易被正确聚合，并在告警阈值设置和跨系统集成时减少误解。
资料来源：OpenTelemetry Semantic Conventions for HTTP Metrics (https://opentelemetry.io/docs/specs/semconv/http/http-metrics/)