为了您方便合理的配置应用设置和帮助系统更稳定运⾏，本文介绍应用异常检测规则。
CPU异常检测规则
数据字段说明
avg_cpu_used：CPU平均利用量（毫核，1核=1000毫核）。p95_cpu_used：CPU利用率P95分位值（毫核）。p99_cpu_used：CPU利用率P99分位值（毫核）。cpu_request：K8s Pod的CPU请求量（资源保障基线）。cpu_limit：K8s Pod的CPU限额量（资源使用上限）。
检测规则详解
1. Limit逼近风险
触发条件：p99_cpu_used > cpu_limit × 0.8
异常类型：限流风险
评分公式：min(100, 70 + (p99_used/limit - 0.8) × 500)
等级划分：
≥90分 → Critical（直接触发内核限流风险）
80-89分 → High（需紧急调整Limit）
70-79分 → Medium（建议监控）
规则说明
设计原理：基于Kubernetes CPU限流机制（CFS配额），当容器CPU使用量持续接近Limit时，会触发内核级限流（throttling）。P99值反映极端场景下的资源消耗情况，80%阈值参考Google SRE黄金指标中的"饱和度"指标设定。
示例：当cpu_limit=2000m（2核），p99_cpu_used=1700m时：
计算比例：1700/2000=0.85
得分=70 + (0.85-0.8) × 500=70+25=95分 → Critical
处理建议：
紧急扩容Limit至少提升25%（2000m→2500m）
使用
kubectl describe node检查节点资源余量
2. 持续性资源不足
触发条件：p95_cpu_used > cpu_request + (cpu_limit - cpu_request) × 0.2
异常类型：资源不足
评分公式：min(100, 80 + (p95_used - request) / (limit - request) × 20)
等级划分：
≥90分 → Critical
80-89分 → High
规则说明
设计原理：基于Kubernetes调度机制，Request是调度保障值，Limit-Request区间为弹性空间。设置20%缓冲区（参考AWS ECS安全缓冲区设计），当P95值突破缓冲区时，说明长期资源需求高于保障基线。
示例：当cpu_request=1000m，cpu_limit=3000m，p95_cpu_used=1500m时：
缓冲区上限=1000 + (3000-1000) × 0.2=1400m
超出量=1500-1400=100m
得分=80 + (100/2000) × 20=81分 → High
处理建议：
调整Request到1400m以上
检查Pod QoS类别是否Burstable
3. 突发负载风险
触发条件：(p95_cpu_used - avg_cpu_used)/avg_cpu_used > 4
异常类型：负载波动
评分公式：60 + 20 × (波动率-4)
等级固定：Medium
规则说明
设计原理：基于经验值，当峰值超过均值4倍时，认为存在异常突发流量。固定Medium等级提醒关注但无需立即处理。
示例：当avg_cpu_used=200m，p95_cpu_used=1000m时：
波动率=(1000-200)/200=4 → 刚好触发
得分=60 + 20 × (4-4)=60分 → Medium
处理建议：
配置HPA自动扩缩容 + 增加pre-stop钩子平滑流量
4. 资源配置冗余
触发条件：avg_cpu_used < cpu_request × 0.4
异常类型：资源浪费
评分公式：70 - (avg_used/request) × 10
等级固定：Medium
规则说明
设计原理：基于经验值，当平均使用量低于Request的40%时，认为存在资源浪费（Google云推荐Request利用率应保持在40%-70%之间）。
示例：当cpu_request=4000m，avg_cpu_used=1500m时：
使用率=1500/4000=0.375
得分=70 - 0.375 × 10=66.5 → Medium
处理建议：
阶梯式下调Request（每次调整不超过20%）
改用Guaranteed QoS类别
5. Limit配置不合理
触发条件：cpu_limit/cpu_request > 4
异常类型：配置风险
评分公式：80 + (limit/request - 4) × 5
等级划分：
≥90分 → Critical
80-89分 → High
规则说明
设计原理：基于经验值，Limit/Request比值超过4:1时（生产环境推荐2:1），可能导致节点资源碎片化，且违反PCI-DSS等安全规范。
示例：当cpu_request=500m，cpu_limit=2500m时：
比值=2500/500=5
得分=80 + (5-4) × 5=85分 → High
处理建议：
调整Limit不超过Request的3倍
检查namespace级ResourceQuota限制
内存异常检测规则
数据字段说明
max_heap_rate_based_request：基于Request的JVM堆内存最大使用率（百分比，如7表示7%）。mem_request：内存Request值（MB，K8s保障资源量）。mem_limit：内存Limit值（MB，K8s资源使用上限）。p95_mem_used_rate：基于Limit的P95内存使用率。p99_mem_used_rate：基于Limit的P99内存使用率。p95_mem_used：P95内存使用量（MB）。p99_mem_used：P99内存使用量（MB）。
检测规则详解
1. Limit逼近风险（最高优先级）
触发条件：p99_mem_used_rate > 0.85
异常类型：内存溢出风险
评分公式：min(100, 80 + [(p99_mem_used_rate - 0.85) × 200])
等级划分：
≥90分 → Critical（直接触发OOM风险）
80-89分 → High（接近Limit但未达临界值）
规则说明
设计原理：基于Kubernetes OOMKill机制（来源：K8s官方文档），当内存使用量超过Limit时容器会被立即终止。设置85%的警戒线，P99反映极端场景下的内存使用情况。
示例：当mem_limit=4096MB，p99_mem_used_rate=0.88时：
超出阈值=0.88-0.85=0.03
得分=80 + 0.03×200=86分 → High
若达到0.9（使用率90%），得分=80+0.05×200=90分 → Critical
处理建议：
紧急扩容Limit至少增加15%
检查内存泄漏：
jmap -histo <pid>
2. 动态资源不足
触发条件：p95_mem_used > mem_request + (mem_limit - mem_request) × 0.2
异常类型：资源不足
评分公式：min(100, 70 + [(p95_mem_used - request)/(1 + mem_limit - mem_request) × 50])
等级划分：
≥90分 → Critical（超过缓冲区50%）
80-89分 → High（超过30%-50%）
70-79分 → Medium（超过20%-30%）
规则说明
设计原理：基于经验值，在Limit-Request区间设置20%缓冲区（计算时+1防止除零）。当P95持续突破缓冲区时，说明Request配置过低（来源：Kubernetes资源配置白皮书）。
示例：当mem_request=2048MB，mem_limit=4096MB，p95_mem_used=2560MB时：
缓冲区上限=2048 + (4096-2048) × 0.2=2457.6MB
超出量=2560-2457.6=102.4MB
得分=70 + [102.4/(1+2048)]×50≈71分 → Medium
处理建议：
调整Request至2458MB以上
配置VerticalPodAutoscaler
3. 资源浪费（Request基准）
触发条件：p95_mem_used < mem_request × 0.6
异常类型：资源浪费
评分公式：min(100, 40 + [(0.6 - p95_mem_used/mem_request) × 150])
等级划分：
≥70分 → High（利用率<15%）
60-69分 → Medium（15%-30%）
40-59分 → Low（30%-40%）
规则说明
设计原理：基于经验值，Request利用率低于60%视为资源浪费。150倍系数使每低1%得1.5分，强化浪费感知。
示例：当mem_request=4096MB，p95_mem_used=1229MB时：
使用率=1229/4096≈0.3
得分=40 + (0.6-0.3) ×150=85分 → High
处理建议：
按30%步长逐步下调Request
改用Burstable QoS类型
4. QoS配置风险
触发条件：mem_limit/mem_request >4 && p95_mem_used<mem_limit×0.5 && (p99_mem_used-p95_mem_used)<mem_limit×0.1
异常类型：配置失当
评分公式：min(100, 60 + [(mem_limit/request -4)×20 - (p95_used/limit×50)])
等级划分：
≥80分 → Critical（比值>6且使用率<15%）
70-79分 → High（比值5-6且使用率<25%）
60-69分 → Medium（比值4-5且使用率<30%）
规则说明
设计原理：基于经验值，Limit/Request比值过大且实际使用率低时，会导致节点资源碎片化。双重条件确保真实存在配置浪费。
示例：当request=1024MB，limit=5120MB，p95_used=768MB时：
比值=5，使用率=768/5120=15%
得分=60 + (5-4)×20 - 0.15×50=60+20-7.5=72.5 → High
处理建议：
调整Limit/Request比值≤3:1
应用ResourceQuota限制
5. 资源浪费（JVM堆基准）
触发条件：max_heap_rate_based_request <40
异常类型：资源浪费
评分公式：min(100,40 + [(0.4 - max_heap_rate/100)×150])
等级划分：
≥70分 → High（利用率≤10%）
60-69分 → Medium（11%-20%）
40-59分 → Low（21%-40%）
规则说明
设计原理：堆内存长期使用率低于Request的40%时，存在明显资源浪费。
示例：当mem_request=2048MB，max_heap_rate=15（即15%）时：
得分=40 + (0.4-0.15)×150=77.5 → High
处理建议：
调整JVM参数：
-Xmx1536m（75% of 2048MB）监控GC日志：
-XX:+PrintGCDetails
Young GC异常检测规则
数据字段说明
max_total_ygc_time：10分钟内Young GC的总时间的最大值（单位：毫秒）。avg_total_ygc_time：10分钟内Young GC的总时间的平均值（单位：毫秒）。max_total_ygc_count：10分钟内Young GC次数的最大值。avg_total_ygc_count：10分钟内Young GC次数的平均值。avg_time_per_ygc：单次Young GC平均耗时（单位：毫秒）。jvm_configurations: 应用使用的jvm启动参数（包含内存配置、垃圾回收器类型等关键参数）。
检测规则详解
1. Young GC总耗时超限
触发条件：max_total_ygc_time > 10000ms
异常类型：性能瓶颈
评分公式：min(100, 60 + [(max_total_ygc_time/10000 - 1) × 20])
等级划分：
≥90分 → Critical（严重阻塞主线程）
80-89分 → High（GC耗时长需优化）
规则说明
设计原理：基于经验值，单实例10分钟内GC总耗时超过10秒（即每分钟超过1秒）将显著影响系统吞吐量。20倍系数表示每分钟超出1秒增加20分，快速反映严重程度。
示例：当检测到max_total_ygc_time=20000ms时：
超出阈值=20000-10000=10000ms
得分=60 + (2-1)×20=80 → High等级
处理建议：
调整年轻代大小：如
-Xmn512m（默认值的2倍）检查对象分配速率：
jstat -gcutil <pid> 1000
2. Young GC频率异常
触发条件：(max_total_ygc_count > 500) AND (avg_time_per_ygc > 20ms)
异常类型：资源浪费
评分公式：min(100, 70 + [(max_total_ygc_count/500 - 1) × 10])
等级划分：
≥80分 → High（频繁GC影响吞吐量）
70-79分 → Medium（需关注内存分配）
规则说明
设计原理：基于经验值，同时满足两个条件时触发。
10分钟内最大GC次数>500次（即每秒>0.83次）。
单次GC耗时>20ms，10倍系数使每多100次增加2分，准确反映资源浪费程度。
示例：当max_total_ygc_count=600次，avg_time_per_ygc=25ms时：
得分=70 + (600/500-1)×10=72分 → Medium
当达到
1000次时：得分=70 + (2-1)×10=80分 → High
处理建议：
优化短生命周期对象：使用对象池化技术
调整Survivor区比例：如
-XX:SurvivorRatio=6
3. 单次GC效率异常
触发条件：avg_time_per_ygc > 60ms
异常类型：性能瓶颈
评分公式：min(100, 70 + (avg_time_per_ygc - 60)
等级划分：
≥90分 → Critical（存在大对象/内存碎片）
80-89分 → High（Survivor区不足）
70-79分 → Medium（Eden区配置过小）
规则说明
设计原理：基于经验值，健康JVM的单次Young GC耗时应小于60ms。
示例：当avg_time_per_ygc=80ms时：
得分=70 + (80-60)=80 → High
处理建议：
检查大对象分配：
jmap -histo:live <pid>调整GC线程数：
-XX:ParallelGCThreads=4启用GC日志分析：
-Xlog:gc*:file=gc.log
Full GC异常检测规则
数据字段说明
max_total_fullgc_time：10分钟内Full GC总耗时的最大值（单位：毫秒）。avg_total_fullgc_time：10分钟内Full GC总耗时的平均值（单位：毫秒）。max_total_fullgc_count：10分钟内Full GC次数的最大值。avg_total_fullgc_count：10分钟内内Full GC次数的平均值。avg_time_per_fullgc：单次Full GC平均耗时（单位：毫秒）。jvm_configurations: 应用使用的jvm启动参数。max_old_size: 最大老年代大小（MB）。avg_old_size: 平均老年代大小（MB）。old_gen_max_capacity: 老年代配置大小（MB）。
检测规则详解
1. 单次Full GC耗时异常
触发条件：avg_time_per_fullgc > 1000ms
异常类型：性能瓶颈
评分公式：min(100, 70 + floor(实际耗时 / 100))
等级划分：
≥90分 → Critical（耗时≥2000ms）
80-89分 → High（1000ms < 耗时 < 2000ms）
规则说明
设计原理：基于经验值，单次Full GC耗时超过1秒将导致STW（Stop-The-World）时间过长，影响服务可用性。每100ms增加1分的线性评分可直观反映严重程度。
示例：当检测到avg_time_per_fullgc=1850ms时：
得分=70 + floor(1850/100)=70+18=88分 → High
若达到2100ms，得分=70+21=91分 → Critical
处理建议：
增加老年代容量：
-XX:OldSize=2048m升级GC算法：
-XX:+UseG1GC检查大对象：
jmap -histo:live <pid>
2. Full GC次数过多
触发条件：max_total_fullgc_count > 3次
异常类型：内存压力
评分公式：min(100, 60 + ((max_total_fullgc_count - 3) × 5))
等级划分：
≥90分 → Critical（次数≥9次）
80-89分 → High（次数7-8次）
65-79分 → Low（次数4-6次）
规则说明
设计原理：基于经验值，健康JVM的Full GC频率应≤3次/10分钟。每多1次增加5分的梯度设计（来源：阿里云ARMS监控系统经验值），能快速识别内存泄漏风险。
示例：当检测到max_total_fullgc_count=7次时：
得分=60 + (7-3) × 5=80分 → High
若达到10次，得分=60+(10-3) × 5=95分 → Critical
处理建议：
检查内存泄漏：
jstat -gcutil <pid> 1000调整晋升阈值：
-XX:MaxTenuringThreshold=8
3. 老年代容量风险
触发条件：
max_old_used > old_gen_max_capacity × 0.8
avg_old_used > old_gen_max_capacity × 0.6
异常类型：配置风险
评分公式：
min(100, 70 + [(max_old_used/capacity - 0.8) × 200])
min(100, 70 + [(avg_old_used/capacity - 0.6) × 150])
等级划分：
≥90分 → Critical（使用率≥90%）
80-89分 → High（使用率85%-89%）
70-79分 → Medium（使用率80%-84%）
规则说明
设计原理：基于经验值。
峰值使用率超过80%易引发内存碎片
平均使用率超过60%预示容量不足
示例
当old_gen_max_capacity=2048MB，max_old_used=1843MB时：
使用率=1843/2048≈0.9
得分=70 + (0.9-0.8) × 200=90分 → Critical
当old_gen_max_capacity=2048MB，avg_old_used=1600MB时：
使用率=1600/2048≈0.8
得分=70 + (0.8-0.6) × 150=100分 → Critical
处理建议：
调整老年代比例：
-XX:NewRatio=3增加堆内存：
-Xmx4096m -Xms4096m对堆内存进行分析