3. 流量（Traffic）指标设计：QPS/RPS、并发连接数与服务网格流量指标
流量指标反映系统当前承载的请求压力，是容量规划、限流降级和异常检测的第一道防线。在容器化环境中，由于实例动态扩缩、服务网格引入额外代理层，流量指标的采集与解读比传统架构更复杂。本节聚焦三个核心维度：QPS/RPS、并发连接数以及Istio Envoy 流量指标。
3.1 QPS/RPS：请求吞吐量
QPS（Queries Per Second）与 RPS（Requests Per Second）在多数场景下可互换使用，均表示每秒到达系统的请求数量。在容器化架构中，QPS 指标需要按实例级和服务级分别监控。
| 维度 | 采集目标 | 典型 PromQL 示例 | 告警阈值参考 |
|---|---|---|---|
| 实例级 QPS | 单个 Pod 入口流量 | sum(rate(istio_requests_total{reporter="destination",destination_workload="reviews-v1"}[1m])) |
超过 Pod 预留 CPU 对应基准 QPS 的 80% |
| 服务级 QPS | 整个 Service 聚合流量 | sum(rate(istio_requests_total{reporter="destination",destination_service="reviews.default.svc.cluster.local"}[1m])) |
超过服务整体容量上限的 70% |
| 上游 QPS | Ingress Gateway 入口 | sum(rate(istio_requests_total{reporter="source",source_workload="istio-ingressgateway"}[1m])) |
与下游服务 QPS 联动，偏差 > 20% 触发 |
实战要点：容器化环境下 QPS 指标必须区分
reporter="source"（客户端视角）与 reporter="destination"（服务端视角）。两者差值反映网络丢包或代理转发延迟，差值超过 5% 应触发排查。
3.2 并发连接数：连接池与线程模型
并发连接数指系统在同一时刻维持的活跃 TCP 连接数量。容器化环境中，每个 Pod 的 sidecar 代理（Envoy）会消耗额外的文件描述符和内存，因此并发连接数指标直接影响 Pod 资源配额。
- Envoy 监听器级别：
envoy_listener_downstream_cx_active— 当前活跃下游连接数 - Envoy 集群级别：
envoy_cluster_upstream_cx_active— 当前活跃上游连接数 - Pod 级别：通过 cAdvisor 采集
container_network_tcp_usage_total估算
连接数爆炸典型场景：当 HPA 触发扩容但新 Pod 尚未就绪时，旧 Pod 的连接数可能瞬时飙升 3-5 倍。建议设置
envoy_cluster_upstream_cx_active 的告警阈值为 Pod 最大连接数 × 0.75，并配合 envoy_cluster_upstream_rq_pending_active（待处理请求数）做二次确认。
3.3 服务网格流量指标：Istio Envoy 核心指标
Istio 通过 Envoy sidecar 注入到每个 Pod，自动生成丰富的流量指标。以下是容器化场景下必须关注的 Envoy 指标分类：
| 指标类别 | 指标名称 | 说明 | 容器化配置影响 |
|---|---|---|---|
| 请求总量 | istio_requests_total |
按 source/destination、response_code、protocol 细分 | sidecar 资源占用与请求量线性相关 |
| 请求延迟 | istio_request_duration_milliseconds |
P50/P90/P99 分位延迟，含 sidecar 处理时间 | 延迟突增可能因 sidecar 资源争抢 |
| 连接数 | istio_tcp_connections_opened_total / _closed_total |
TCP 连接生命周期统计 | 连接频繁开闭增加 sidecar CPU 开销 |
| 重试与超时 | istio_requests_total{response_flags="-"} 排除重试 |
区分原始请求与重试请求 | 重试风暴可能导致 sidecar 内存 OOM |
3.4 流量指标在容器化参数配置中的实战映射
流量指标直接决定以下容器化参数的初始值与动态调整策略：
- HPA 扩缩容阈值：基于
istio_requests_total的 rate 值设定目标 QPS/Pod，例如targetAverageValue: 200表示每个 Pod 达到 200 QPS 时触发扩容。 - Pod 资源 request/limit：根据 P99 并发连接数 × 单连接内存开销（Envoy 约 1-2 KB/连接）计算 sidecar 内存需求。
- 连接池限制：Envoy 的
circuitBreakers配置中maxConnections应参考历史峰值并发连接数的 1.5 倍。 - 重试策略：当
istio_requests_total{response_code="503"}占比超过 1% 时，应减少重试次数或启用快速失败。
避坑指南：不要直接使用
container_cpu_usage_seconds_total 推导 QPS 容量。容器化环境下 CPU 节流（throttling）会导致 QPS 与 CPU 使用率脱钩。应优先使用 Envoy 的请求指标作为扩缩容依据，CPU 指标仅作为辅助参考。
3.5 流量指标黄金信号仪表盘设计
以下为容器化环境流量指标的最小可行仪表盘（Grafana）面板清单：
| 面板名称 | 指标来源 | 聚合方式 | 可视化类型 |
|---|---|---|---|
| 全局 QPS 趋势 | istio_requests_total |
sum by (destination_service) | 时间序列折线图 |
| 服务间流量拓扑 | istio_requests_total |
sum by (source_workload, destination_workload) | 桑基图 / 力导向图 |
| 并发连接数热力图 | envoy_cluster_upstream_cx_active |
avg by (pod) | 热力图 / 状态面板 |
| 错误率与重试率 | istio_requests_total{response_code=~"5.."} |
rate / sum by (destination_service) | 堆叠面积图 |
| P99 延迟与 QPS 联合视图 | istio_request_duration_milliseconds + istio_requests_total |
histogram_quantile + rate | 双轴图（柱状+折线） |
3.6 流量指标参数配置清单
以下为容器化环境下基于流量指标的参数配置速查表：
| 配置项 | 关联指标 | 推荐初始值 | 动态调整依据 |
|---|---|---|---|
| HPA target QPS | istio_requests_total rate |
200 QPS / Pod | P99 延迟超过 500ms 时降低目标值 |
| Envoy 连接池 maxConnections | envoy_cluster_upstream_cx_active |
500 | 达到 80% 使用率时增加 50% |
| Pod sidecar 内存 limit | envoy_cluster_upstream_cx_active × 2KB |
256 MiB | 连接数峰值 × 2KB + 20% 余量 |
| 重试次数上限 | istio_requests_total{response_code="503"} 占比 |
2 次 | 占比 > 2% 时降为 1 次或关闭重试 |
| 熔断器 maxPendingRequests | envoy_cluster_upstream_rq_pending_active |
100 | 待处理请求数持续 > 80 时触发熔断 |
推荐实践：在容器化环境中，流量指标应作为第一优先级的 Golden Signal。建议在 Istio 安装时启用
--set meshConfig.enablePrometheusMerge=true，使 Prometheus 自动合并 sidecar 与业务应用的指标，避免指标采集遗漏。