4. 容量水位概念：CPU、内存、磁盘、网络IO等核心指标定义、水位阈值设定原则、健康度评分模型
在平台工程与Backstage插件集成场景中，容量水位是指IT资源（计算、存储、网络）当前使用量相对于其最大可用容量的比例。准确理解并量化这些指标，是构建自动化巡检与健康度评估的基础。本章将系统定义核心指标、阐述阈值设定原则，并给出可落地的健康度评分模型。
4.1 核心指标定义
容量水位巡检通常覆盖以下四大类资源，每类资源对应多个关键指标。下表列出了最常用的指标及其业务含义：
| 资源类别 | 指标名称 | 单位 | 定义与说明 |
|---|---|---|---|
| CPU | CPU使用率 | % | CPU处于非空闲状态的时间百分比。反映计算负载强度。 |
| CPU Load Average | 数值 | 特定时间窗口内（1/5/15分钟）处于可运行或不可中断状态的进程平均数。需结合CPU核数解读。 | |
| 内存 | 内存使用率 | % | 已用物理内存（不含缓存/缓冲区）占总物理内存的比例。 |
| Swap使用率 | % | 已用交换空间占总交换空间的比例。Swap使用率持续升高通常意味着物理内存不足。 | |
| 磁盘 | 磁盘使用率 | % | 已用磁盘空间占总容量的比例。关注根分区、数据盘、日志盘。 |
| 磁盘IOPS | 次/秒 | 每秒读写操作次数。反映磁盘的并发处理能力。 | |
| 网络IO | 网络带宽使用率 | % | 当前网络吞吐量占网卡最大带宽的比例。 |
| 网络连接数 | 个 | 当前处于ESTABLISHED状态的TCP连接数。过高可能导致端口耗尽或连接超时。 |
实践建议：在Backstage插件中，建议将上述指标统一采集并存储为时间序列数据（如Prometheus Metrics），便于后续阈值判定与趋势分析。
4.2 水位阈值设定原则
阈值设定并非一成不变，需遵循以下核心原则，以确保巡检结果既不过于敏感也不过于迟钝：
- 分层设定原则：不同资源、不同环境（开发/测试/生产）应使用不同的阈值。生产环境阈值通常更严格。
- 动态基线原则：基于历史数据（如过去7天或30天）自动计算动态基线，而非仅依赖固定阈值。例如，CPU使用率在业务高峰期的基线可能为60%，而在低谷期为10%。
- 多级告警原则：设置至少三个水位等级——警告（Warning）、严重（Critical）、紧急（Emergency），分别对应不同的响应策略。
- 资源特性原则：CPU和内存可容忍短时突增，但磁盘使用率一旦超过阈值通常难以自动恢复，需设置更保守的阈值。
下表展示了典型的生产环境阈值参考值（以x86服务器为例）：
| 资源指标 | 警告阈值 | 严重阈值 | 紧急阈值 | 说明 |
|---|---|---|---|---|
| CPU使用率 | 70% | 85% | 95% | 持续超过5分钟触发 |
| 内存使用率 | 75% | 85% | 92% | 不含缓存/缓冲区 |
| 磁盘使用率 | 75% | 85% | 92% | 根分区建议更严格 |
| 网络带宽使用率 | 60% | 75% | 90% | 持续超过10分钟触发 |
避坑提示：避免对所有资源使用统一的“80%”阈值。例如，磁盘使用率达到80%时，若业务数据持续增长，可能在数小时内就会达到100%，导致服务不可用。建议对磁盘使用率设置更低的警告阈值（如70%），并配合增长趋势预测。
4.3 健康度评分模型
健康度评分模型将多个维度的容量水位指标综合为一个0-100分的数值，便于在Backstage服务目录中直观展示。模型设计需兼顾准确性与可解释性。
4.3.1 评分模型架构
下图展示了健康度评分模型的整体架构与计算流程：
4.3.2 单指标评分函数
对于每个指标，采用分段线性评分函数。以CPU使用率为例：
// 伪代码：CPU使用率评分
function scoreCPU(usagePercent):
if usagePercent <= 70:
return 100
else if usagePercent <= 85:
// 70% ~ 85% 之间线性递减
return 100 - (usagePercent - 70) * (30 / 15)
else if usagePercent <= 95:
// 85% ~ 95% 之间线性递减
return 70 - (usagePercent - 85) * (40 / 10)
else:
// 超过95% 直接扣至低分
return 30
4.3.3 综合评分公式
最终健康度评分 = Σ(单指标评分 × 权重) - 惩罚项。权重分配建议如下：
| 指标 | 默认权重 | 权重依据 |
|---|---|---|
| CPU使用率 | 25% | 直接影响服务响应速度 |
| 内存使用率 | 25% | 内存不足导致OOM或Swap抖动 |
| 磁盘使用率 | 25% | 磁盘写满可能导致数据丢失或服务崩溃 |
| 网络带宽使用率 | 15% | 网络瓶颈影响外部访问 |
| 磁盘IOPS | 10% | IOPS过高影响数据库等IO密集型应用 |
惩罚项规则：当任意指标处于“紧急”状态时，额外扣除20分；当两个及以上指标同时处于“紧急”状态时，额外扣除40分。此设计可防止单一资源严重过载时评分仍虚高。
4.3.4 评分等级映射
最终评分可映射为Backstage服务目录中的健康度标签，便于运维人员快速识别：
- 健康（90-100分）：绿色标签，表示容量充足，无需干预。
- 亚健康（70-89分）：黄色标签，表示存在潜在风险，建议关注趋势。
- 警告（50-69分）：橙色标签，表示需要制定扩容或优化计划。
- 危险（0-49分）：红色标签，表示需要立即介入处理。
4.4 在Backstage插件中的集成示意
以下SVG图展示了容量水位评分数据如何在Backstage插件中流转与展示：
落地建议：在Backstage插件中，建议将健康度评分作为服务实体的一个自定义属性（
spec.healthScore）存储，并利用Backstage的EntitySwitch组件实现不同评分等级展示不同颜色与操作按钮。