4. 资源监控与度量：监控指标、采集方法与监控工具
4.1 核心原理：从“盲人摸象”到“全景可观测”
多租户资源争抢诊断的第一步，是建立一套可量化、可对比、可追溯的监控体系。没有监控，一切调优都是猜测。但仅仅有监控还不够——如果只盯着单一指标（如CPU使用率），很容易陷入“盲人摸象”的误区。例如，某租户的CPU使用率只有30%，但业务延迟却飙升，原因可能是CPU steal（虚拟机等待物理CPU调度的时间）过高，或是L3缓存命中率骤降。因此，监控必须覆盖资源使用量、资源饱和度、资源争抢程度、服务质量四个维度，形成一张完整的“压力地图”。
下图展示了多租户环境下从物理资源到租户业务的可观测性分层模型，以及各层对应的关键监控指标。
该模型的核心价值在于分层关联：当租户业务层出现延迟时，可以逐层下钻，判断是物理资源耗尽、虚拟化调度争抢，还是租户自身应用瓶颈。例如，若L3的RT升高，同时L2的CPU steal从1%升至15%，则可判定为CPU争抢；若L2正常而L1的磁盘util已达95%，则属于物理磁盘瓶颈。
4.2 方法流程：监控指标体系的搭建与采集
搭建一套有效的多租户监控体系，建议遵循以下五步流程：
- 定义SLO与关键指标：为每个租户定义服务质量目标（如RT p99 < 200ms），并拆解为可监控的技术指标。
- 选择采集粒度与频率：系统级指标建议5~15秒采集一次，业务级指标可放宽至30~60秒。争抢诊断场景需要保留至少7天的历史数据。
- 部署采集代理：在宿主机部署Node Exporter，在虚拟机/容器内部署cAdvisor或租户级Agent，确保覆盖L1~L3全部层级。
- 建立指标关联视图：将CPU steal、就绪队列、磁盘延迟等争抢敏感指标与租户业务指标组合成仪表盘。
- 设置动态阈值告警：基于历史基线设置告警，例如CPU steal超过基线2倍持续5分钟即触发。
以下是一个典型的Prometheus采集配置片段，用于抓取宿主机和租户VM的指标：
# prometheus.yml 关键配置
scrape_configs:
- job_name: 'node-exporter' # 宿主机物理指标
static_configs:
- targets: ['192.168.1.10:9100']
labels:
host_type: 'physical'
- job_name: 'cadvisor' # 容器/VM指标
static_configs:
- targets: ['192.168.1.10:8080']
labels:
host_type: 'hypervisor'
- job_name: 'tenant-app' # 租户业务指标
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['10.0.0.11:8081', '10.0.0.12:8081']
labels:
tenant_id: 'tenant-a'4.3 监控工具实战：Prometheus + Grafana 组合
Prometheus与Grafana是当前多租户监控事实上的标准组合。Prometheus负责指标采集与存储，Grafana负责可视化与告警。在争抢诊断场景中，以下四类查询最为常用：
| 诊断目标 | PromQL 查询示例 | 争抢判定参考 |
|---|---|---|
| CPU 争抢 | avg by (instance) (rate(node_cpu_steal_seconds_total[5m])) |
steal > 5% 且伴随RT上升 |
| 内存带宽争抢 | rate(node_memory_bandwidth_total_bytes[1m]) |
接近物理内存通道上限 |
| 磁盘争抢 | histogram_quantile(0.99, sum by (le) (rate(node_disk_io_time_weighted_seconds[5m]))) |
p99 > 50ms 或 IOPS 达上限 |
| 网络争抢 | rate(node_network_receive_drop_total[5m]) |
丢包率 > 0.1% |
在Grafana中，建议为每个租户创建独立的Dashboard变量，通过$tenant_id标签过滤指标。同时，将CPU steal、就绪队列、磁盘延迟、租户RT四个指标放在同一时间轴面板中，便于观察争抢与业务影响的因果关系。
recording rules预计算争抢指数。例如，定义规则tenant_cpu_steal_ratio = avg(rate(node_cpu_steal_seconds_total[5m])) by (instance)，将高频查询转为低开销的预聚合结果，可显著提升大集群下的Grafana响应速度。
4.4 案例场景：一次内存带宽争抢的监控复盘
背景：某金融云平台共有3台物理宿主机（每台双路CPU，8通道DDR4内存），承载约40个租户VM。近期租户A反馈其数据库查询延迟从平均8ms飙升至45ms，但CPU使用率仅35%。
监控排查过程：
- 首先查看Grafana中租户A的CPU steal指标，发现仅0.5%，排除CPU调度争抢。
- 检查磁盘延迟，p99为12ms，处于正常范围。
- 进一步查看宿主机内存带宽指标，发现物理机1的内存带宽利用率已达92%，而其他两台仅40%左右。
- 通过Prometheus按VM维度聚合内存带宽，定位到同宿主机上的租户B正在运行大规模数据挖掘任务，其内存带宽占用率高达60%。
- 确认争抢关系：租户B的内存带宽密集型负载导致内存控制器饱和，租户A的缓存命中率下降，进而引发延迟飙升。
解决方案：通过将租户B的部分VM迁移至内存带宽空闲的物理机2，租户A的延迟在10分钟内恢复至9ms。后续通过Grafana设置内存带宽利用率超过80%时自动告警，避免类似争抢再次发生。
4.5 误区与复盘：监控数据“有”不等于“有用”
在监控体系建设中，最常见的误区包括：
- 指标过多但无关联：采集了数百个指标，却未建立跨层关联视图，导致争抢发生时无法快速定位。
- 采样频率过低：争抢往往是秒级甚至毫秒级现象，若采样间隔为5分钟，可能完全错过争抢窗口。
- 忽略基线对比：未保存历史基线数据，无法判断当前指标是“异常”还是“常态”。
- 告警阈值静态化：不同租户的业务特征差异大，统一阈值会导致大量误报或漏报。
复盘建议：每季度对监控体系进行一次“红蓝对抗”演练——人为制造一次CPU或内存带宽争抢，检验监控系统能否在5分钟内定位到争抢源租户。同时，将监控数据与调度系统联动，当争抢指标超过阈值时，自动触发VM迁移或配额限制，形成“监控-诊断-调优”的闭环。