4. 容量压测水位口径定义:什么是水位?常见口径(CPU、内存、QPS、延迟)及其在日志中的体现
在容量压测与稳定性保障中,“水位”是衡量系统负载程度与资源消耗的核心概念。它不是一个单一的指标,而是一组经过口径对齐的阈值集合,用于判断系统是否处于健康、警戒或过载状态。本节将系统性地定义水位,并拆解 CPU、内存、QPS、延迟四大常见口径,以及它们在日志中的具体体现方式。
4.1 什么是水位?
水位(Water Level)借鉴自水利工程中的“水位线”概念,在分布式系统中指系统在特定负载下资源使用率与服务质量之间的临界点。当水位超过设计阈值时,系统性能可能出现非线性劣化,甚至引发雪崩。
核心公式: 水位 = 实际资源消耗 / 容量上限 × 100%
水位口径 = 指标类型 + 采集方式 + 阈值定义 + 持续时间
水位口径 = 指标类型 + 采集方式 + 阈值定义 + 持续时间
水位口径的标准化是压测数据可比、可复现的前提。不同团队对“CPU 高水位”的定义可能相差 20%,因此必须在压测方案中明确每个口径的采集粒度、聚合窗口与告警边界。
4.2 四大常见水位口径
| 口径 | 典型阈值 | 采集粒度 | 聚合窗口 | 告警边界 |
|---|---|---|---|---|
| CPU 水位 | ≤ 70% 安全 / 70-85% 警戒 / > 85% 过载 | 10s | 1min 均值 | 连续 3 个窗口 > 85% |
| 内存水位 | ≤ 75% 安全 / 75-90% 警戒 / > 90% 过载 | 30s | 5min 均值 | 连续 2 个窗口 > 90% |
| QPS 水位 | ≤ 80% 容量上限 / 80-95% 警戒 / > 95% 过载 | 1s | 10s 均值 | 单窗口 > 95% 容量 |
| 延迟水位 | P99 ≤ 200ms 安全 / 200-500ms 警戒 / > 500ms 过载 | 1s | 1min P99 | 连续 3 个窗口 > 500ms |
口径对齐要点: 压测报告中的“CPU 水位 80%”必须注明是
user + system 还是仅 user,是否包含 iowait,以及聚合窗口是 1min 均值还是 5min 均值。口径不一致会导致误判。
4.3 水位在日志中的体现
日志是水位监控的“最后一公里”。指标(Metrics)告诉我们“水位高了”,日志(Logs)告诉我们“为什么高”。以下通过 Loki 查询示例展示每种水位口径在日志中的典型体现。
4.3.1 CPU 水位日志体现
当 CPU 水位超过警戒线时,应用日志中常出现调度延迟、线程阻塞、GC 停顿等信号。
# Loki LogQL 示例:查找 CPU 高水位期间的 GC 停顿日志
{app="order-service", env="prod"}
| json
| gc_pause_ms > 100
| __timestamp__ >= now() - 5m
典型日志行:
2025-03-20 14:23:45.678 [gc] GC pause: 320ms, threads: 48, cpu_usage: 92%
4.3.2 内存水位日志体现
内存水位过高时,OOM Killer、堆外内存泄漏、频繁 Full GC 是常见日志特征。
# Loki LogQL 示例:查找内存水位超限时的 OOM 日志
{app="payment-service"}
|~ "(?i)out of memory|OOM|heap space|native memory exhausted"
典型日志行:
2025-03-20 14:25:12.345 [ERROR] java.lang.OutOfMemoryError: Java heap space
at com.example.cache.LocalCache.put(LocalCache.java:45)
4.3.3 QPS 水位日志体现
QPS 水位接近容量上限时,日志中会出现连接池耗尽、请求排队、超时重试等模式。
# Loki LogQL 示例:查找 QPS 高水位时的连接池耗尽日志
{app="gateway"}
| json
| pool_active == pool_max
| __timestamp__ >= now() - 1m
典型日志行:
2025-03-20 14:26:01.234 [WARN] Thread pool exhausted: active=200, max=200, queue=150
4.3.4 延迟水位日志体现
延迟水位恶化时,日志中会出现慢查询、外部调用超时、重试风暴等关键信号。
# Loki LogQL 示例:查找延迟水位超限时的慢查询日志
{app="user-service"}
| json
| duration_ms > 500
| __timestamp__ >= now() - 10m
典型日志行:
2025-03-20 14:27:33.456 [WARN] Slow SQL: SELECT * FROM orders WHERE user_id=?, duration=1234ms
4.4 水位口径与日志的关联模型
下图展示了水位口径从指标采集到日志关联的完整链路,帮助理解“指标告警 → 日志定位 → 根因分析”的闭环。
4.5 水位口径定义清单(压测方案必备)
在压测方案中,每个水位口径必须包含以下 6 个要素,缺一不可:
- 指标名称:如
cpu_usage_percent、memory_used_percent、qps_total、latency_p99_ms - 采集方式:Prometheus Node Exporter / cAdvisor / 应用埋点 / 中间件指标
- 聚合窗口:1min 均值 / 5min 均值 / 10s 滑动窗口
- 阈值定义:安全线、警戒线、过载线(含持续时间条件)
- 日志关联键:用于 Loki 查询的 label 组合,如
{app, env, instance} - 日志模式:水位超限时预期出现的日志关键词或正则模式
常见误区: 很多团队只定义指标阈值,却忽略了“日志关联键”和“日志模式”。这导致告警触发后,运维人员需要手动拼接查询条件,平均定位时间增加 3-5 分钟。正确的做法是在压测方案中预先写好 LogQL 查询模板,水位告警直接携带查询链接。
4.6 水位口径的压测验证方法
在压测执行前,必须对每个水位口径进行预验证,确保指标采集、日志输出、告警触发三者一致。验证步骤如下:
| 步骤 | 操作 | 预期结果 | 验证工具 |
|---|---|---|---|
| 1 | 构造 CPU 压力(stress-ng --cpu 4) | CPU 水位 > 85%,日志出现调度延迟 | top / Loki LogQL |
| 2 | 构造内存压力(分配大对象) | 内存水位 > 90%,日志出现 OOM 或 GC 停顿 | free -m / Loki LogQL |
| 3 | 构造 QPS 压力(wrk 并发请求) | QPS 水位 > 95%,日志出现连接池耗尽 | wrk / Loki LogQL |
| 4 | 构造延迟压力(慢 SQL / 外部超时) | 延迟水位 > 500ms,日志出现慢查询 | JMeter / Loki LogQL |
效率提升技巧: 将上述验证步骤写成自动化脚本,每次压测前自动执行。脚本输出“水位口径验证报告”,包含指标曲线截图和日志样本,确保口径定义与实际系统行为一致。这可以避免压测中途发现口径定义错误导致的返工。