4. 慢查询定义与度量：延迟、吞吐量、错误率 (SLI/SLO) 以及 P99/P95/P50 分位延迟的计算方法

在 Kubernetes 环境下定位 Go 服务慢查询，首先需要建立统一的度量体系。没有精确的度量，任何优化都是盲目的。本节将定义慢查询的核心指标，并深入讲解 SLI/SLO 的设定逻辑，以及分位延迟的计算与工程实践。

4.1 核心度量指标：延迟、吞吐量、错误率

慢查询的判定不能仅凭单一维度。我们采用业界通用的 USE 方法论（利用率、饱和度、错误）与 RED 方法论（速率、错误、持续时间）的结合，聚焦以下三个黄金指标：

4.2 SLI 与 SLO：从指标到服务等级目标

SLI (Service Level Indicator) 是实际测量的指标值，SLO (Service Level Objective) 是团队承诺的目标边界。在 K8s 环境中，我们通常为每个 Go 服务定义以下 SLI/SLO：

• SLI 示例： 过去 5 分钟内，P99 延迟为 350ms。
• SLO 示例： 过去 30 天内，P99 延迟 ≤ 500ms 的时间占比 ≥ 99.9%。

设定 SLO 时需遵循 SMART 原则：

1. 具体 (Specific)： 明确是 P99 还是 P95，是 HTTP 请求还是 gRPC 调用。
2. 可衡量 (Measurable)： 必须能被 Prometheus 等工具持续采集。
3. 可达成 (Achievable)： 基于历史数据，不要设定不切实际的 99.999%。
4. 相关 (Relevant)： 与用户体验直接挂钩，例如 API 响应时间。
5. 有时限 (Time-bound)： 以滚动窗口（如 28 天）计算。

4.3 P99 / P95 / P50 分位延迟的计算方法

分位延迟是衡量慢查询最敏感的指标。平均延迟 (Avg) 容易被极端值掩盖，而分位值能精确反映尾部延迟。

4.3.1 计算方法：T-Digest 与 Histogram

在分布式系统中，我们无法存储所有请求的延迟。因此，采用 近似分位算法：

• T-Digest： 目前最流行的算法，在 Prometheus 的 histogram_quantile 函数中默认使用。它将数据点聚类，在尾部（高延迟区域）保持高精度，在头部（低延迟区域）牺牲精度以节省内存。
• HDR Histogram： 高动态范围直方图，适合对精度要求极高的场景，但内存消耗较大。

PromQL 计算示例：

# 计算过去 5 分钟内，HTTP 请求的 P99 延迟（单位：秒）
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket{job="my-go-service"}[5m])) by (le)
)

4.3.2 分位值的工程解读

4.4 分位延迟与资源调整的关联 SVG 图

下图展示了从原始延迟数据到分位计算，再到触发资源调整策略的完整链路：

4.5 实战：在 K8s 中配置分位延迟告警

以下是一个完整的 Prometheus 告警规则示例，用于检测 Go 服务的慢查询：

groups:
- name: go-service-slow-query
  rules:
  - alert: HighP99Latency
    expr: |
      histogram_quantile(0.99,
        sum(rate(http_request_duration_seconds_bucket{job="my-go-service"}[5m])) by (le)
      ) > 0.5
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Go 服务 P99 延迟超过 500ms"
      description: "当前 P99 延迟为 {{ $value }}s，已持续 5 分钟。"

  - alert: HighErrorRate
    expr: |
      sum(rate(http_requests_total{job="my-go-service", status=~"5.."}[5m]))
      /
      sum(rate(http_requests_total{job="my-go-service"}[5m])) > 0.01
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "错误率超过 1%"