2. 容量水位基础概念

容量水位（Capacity Watermark）是衡量系统资源使用程度的核心抽象，它将物理或虚拟资源的消耗量映射为0%–100%的连续标度，使运维人员能够直观判断系统是否处于健康、预警或危险区间。本节从水位定义出发，逐一拆解关键指标与阈值设定原则，为后续的巡检、压测与预测奠定度量基础。

2.1 水位定义与度量模型

水位本质上是一个归一化利用率，其通用计算公式为：

水位（%）= （当前资源使用量 / 资源总量） × 100%

在实际平台中，资源总量可以是物理上限、容器Limit、云实例规格或集群可调度容量。水位模型通常分为三层：

• 瞬时水位：单次采样点的实时利用率，用于告警触发。
• 滑动窗口水位：过去N分钟（如5min、15min）的平均或P99水位，用于趋势判断。
• 基线水位：历史同期或业务低峰期的典型水位，用于异常检测。

2.2 关键指标详解

在模板服务目录平台中，容量水位关注四大类资源指标。每类指标需结合平台特性（容器化、物理机、云实例）选择不同的采集粒度与聚合方式。

2.3 水位阈值设定原则

阈值设定是容量管理中最容易产生分歧的环节。以下五条原则经过多个大规模集群验证，可作为通用参考：

1. 业务优先原则：阈值必须与SLA/SLO绑定。核心交易链路的水位阈值应比非核心服务严格10%–15%。
2. 资源类型差异化原则：CPU可容忍短时突刺（秒级），内存突刺可能导致OOM，磁盘空间接近100%将直接导致写失败。因此各类指标的预警/危险阈值不应统一。
3. 滑动窗口缓冲原则：预警阈值应预留至少15%的缓冲空间，避免因瞬时抖动触发大量无效告警。危险阈值则需考虑故障恢复时间（MTTR）内的资源消耗增长。
4. 动态基线修正原则：固定阈值无法适应业务潮汐变化。建议基于历史7天/30天的P80水位自动计算动态基线，并设定偏移量（如基线+20%为预警）。
5. 压测验证原则：所有阈值在设定后必须通过容量压测进行反向验证。若压测中系统在阈值到达前已出现性能拐点，则阈值应向下调整。

2.4 水位数据采集与聚合策略

水位数据的质量直接决定容量预测的准确性。在模板服务目录平台中，建议采用以下采集与聚合策略：

• 采集端：使用Prometheus Node Exporter + cAdvisor（容器场景）+ 自定义Exporter（中间件/数据库），统一暴露/metrics端点。
• 存储端：时序数据库（VictoriaMetrics / Thanos）保留原始数据7天，降采样数据保留90天。
• 聚合规则：

# 示例：Prometheus recording rules 聚合水位
groups:
  - name: capacity_watermark
    rules:
      - record: node:cpu_usage_avg_5m
        expr: avg by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m]))
      - record: node:memory_usage_avg_5m
        expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100
      - record: node:disk_usage_avg_5m
        expr: max by (instance, mountpoint) (node_filesystem_size_bytes{fstype!="tmpfs"} - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100
      - record: node:network_bandwidth_usage_avg_5m
        expr: rate(node_network_receive_bytes_total[5m]) / 1024 / 1024

2.5 水位与容量预测的关联

水位是容量预测的输入特征，而非预测目标。预测模型通常使用历史水位序列（如过去30天的P80/P95水位）外推未来7–30天的水位趋势。在模板服务目录平台中，每个服务模板的水位数据会作为特征向量输入到预测引擎中，结合业务增长系数（如QPS增长率）生成容量建议。