2. 容量度量指标：定义与采集方法
容量规划的起点是可量化的度量指标。没有指标，规划就是猜测。本节定义六大核心指标——QPS、TPS、并发数、响应时间、资源利用率，并给出生产级采集方法。
2.1 核心指标定义
| 指标 | 英文全称 | 定义 | 典型单位 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数，侧重读请求（如搜索、列表页） | req/s |
| TPS | Transactions Per Second | 每秒事务数，侧重写或完整业务操作（如下单、支付） | tps |
| 并发数 | Concurrency | 系统同时处理的请求/连接数（含排队中） | 个 |
| 响应时间 | Response Time / Latency | 从请求发出到收到完整响应的时间 | ms / s |
| CPU 利用率 | CPU Utilization | CPU 处于非空闲状态的时间百分比 | % |
| 内存利用率 | Memory Utilization | 已用内存占总内存的百分比 | % |
| 磁盘利用率 | Disk Utilization | 磁盘 I/O 时间占比或空间使用率 | % |
| 网络利用率 | Network Utilization | 网络带宽已用占比 | % / bps |
关键区分：QPS 与 TPS 不可混用。读多写少的系统（如内容分发）以 QPS 为主；写密集型系统（如交易、账务）以 TPS 为主。并发数 ≠ QPS，两者通过 Little's Law 关联：
并发数 = QPS × 平均响应时间。
2.2 指标间关系：Little's Law 与利用率模型
以下 SVG 展示了容量规划中最核心的指标关系模型：
SRE 经验：不要只看平均值。P99 响应时间才是容量瓶颈的放大镜。一个系统平均响应时间 50ms，但 P99 可能达到 500ms，此时并发数会急剧膨胀，导致资源利用率虚高。
2.3 采集方法
2.3.1 应用层指标（QPS / TPS / 响应时间）
- 反向代理层采集：Nginx / Envoy 的 access log 或 Prometheus metrics，按
status、upstream聚合。 - 应用框架埋点：Spring Boot Actuator + Micrometer、Go pprof、Python Django Prometheus 客户端。
- APM 工具：SkyWalking、Jaeger、Datadog APM，自动追踪调用链并计算 TPS 与延迟分位值。
- 自定义指标：业务关键路径（如下单、支付）通过 Prometheus Histogram 或 Summary 暴露。
# Prometheus 指标示例（Java Micrometer）
http_server_requests_seconds_count{method="POST",uri="/api/order",status="200"} 12450
http_server_requests_seconds_sum{method="POST",uri="/api/order",status="200"} 623.4
# QPS = rate(http_server_requests_seconds_count[1m])
# 平均响应时间 = rate(sum[1m]) / rate(count[1m])2.3.2 并发数采集
| 层级 | 采集方式 | 典型工具 |
|---|---|---|
| TCP 连接级 | ss -s 或 /proc/net/sockstat | node_exporter |
| 应用线程池 | JMX / Actuator / ThreadPoolExecutor metrics | Micrometer + Prometheus |
| 数据库连接池 | HikariCP / Druid 监控面板 | Spring Boot Actuator |
| 消息队列 | Consumer Lag + 活跃消费者数 | Kafka Exporter / RabbitMQ API |
2.3.3 资源利用率采集
以下表格列出四大资源的采集方法与关键指标：
| 资源 | 关键指标 | 采集命令/工具 | 告警阈值参考 |
|---|---|---|---|
| CPU | user / system / iowait / steal | top, htop, /proc/stat, node_exporter | 持续 > 80% 或 iowait > 10% |
| 内存 | used / available / cached / swap usage | free -m, /proc/meminfo, node_exporter | 可用内存 < 10% 或 swap 持续增长 |
| 磁盘 | iops / throughput / await / util% | iostat -x 1, /proc/diskstats, node_exporter | util > 90% 或 await > 30ms |
| 网络 | 带宽使用率 / 丢包率 / 重传率 | sar -n DEV, iftop, node_exporter | 带宽 > 80% 或重传率 > 1% |
常见陷阱：
- CPU 利用率只看整体会漏掉单核打满（如 Go GC、Java CMS 线程）。务必采集 per-core 指标。
- 磁盘 util% 在 SSD 上意义有限，应同时关注 IOPS 与延迟分位值。
- 网络带宽利用率在云环境需区分内网 vs 外网，外网带宽通常更昂贵且受限。
2.4 采集架构与工具选型
以下 SVG 展示生产级指标采集的典型架构：
Backstage 集成建议：在 Backstage 的
catalog-info.yaml 中通过 spec.metrics 字段声明组件的关键指标锚点，配合 grafana/dashboard 插件实现“资源卡片 → 实时指标”的一键跳转，避免 SRE 在多个系统间切换。
2.5 指标采集避坑清单
- 采样周期过短（如 1s）导致 Prometheus 存储膨胀，建议 10-15s 为基准。
- 忽略冷启动与 JIT 预热：Java / Go 服务刚启动时指标偏低，应过滤前 5 分钟数据。
- 响应时间未区分网络延迟：客户端采集的响应时间包含网络 RTT，服务端采集才反映真实处理能力。
- 并发数误用连接数：HTTP Keep-Alive 连接数远大于实际处理线程数，应采集活跃请求数而非连接数。
- 磁盘空间与磁盘 I/O 混淆：空间利用率 90% 不一定会导致 I/O 瓶颈，反之亦然。两个指标必须分开监控。