4. 资源指标监控与告警策略：CPU、内存、网络、磁盘、GC、连接数等关键指标与阈值设定
容量规划的核心在于“可观测”与“可控制”。面试官通过本章题目重点考察你对关键资源指标的完整认知、阈值设定方法论以及告警策略设计的实战经验。以下从六大指标维度、阈值分层模型到面试高频问答，帮你构建体系化回答框架。
| 指标维度 | 关键监控项 | 参考阈值（告警 / 严重） | 典型场景说明 |
|---|---|---|---|
| CPU | 使用率、Load Average、上下文切换 | 70% / 90% | 计算密集型服务（如数据聚合、编解码）优先关注 |
| 内存 | 使用率、Swap I/O、OOM 事件 | 75% / 90% | 缓存型服务（如 Redis、本地缓存）需预留 buffer |
| 网络 | 带宽使用率、TCP 连接数、丢包率 | 80% / 95% | 网关、API 代理、跨机房同步场景关键 |
| 磁盘 | 使用率、IOPS、读写延迟 | 80% / 95% | 日志密集型应用、消息队列持久化场景 |
| GC | YoungGC 频率、FullGC 频率、STW 时长 | ≤10 次/分 / ≤1 次/时 · 200ms | Java 微服务 RT 抖动根因之一，必须纳入监控 |
| 连接数 | 活跃连接数、空闲连接数、等待队列长度 | 75% / 90%（连接池水位） | 数据库连接池、HTTP 连接池、gRPC 连接池 |
面试加分提示： 面试时不要只背阈值数字，要补充“为什么是这个值”——例如：CPU 70% 告警是为了给突发流量和 GC 留出 buffer，90% 严重阈值触发自动弹性扩容。
Q1：微服务容量规划中哪些资源指标最关键？阈值如何设定？
回答框架：
- 分维度列举：CPU、内存、网络、磁盘、GC、连接数六大维度
- 基线建立：基于业务历史峰值 × 1.5 倍冗余，区分正常水位与告警水位
- 阈值策略：多级阈值（告警 / 严重 / 降级），结合静态与动态调整
简短示例回答：
CPU 70% 告警、90% 严重；内存 75%/90%；GC YoungGC 频率 ≤10 次/分钟，FullGC ≤1 次/小时；连接池水位 80% 告警。所有阈值基于业务峰值 ×1.5 设定，并随大促、压测结果动态调优。
可能追问： “CPU 使用率 70% 告警的依据是什么？如果服务是 CPU 密集型的怎么调整？”
⚠️ 避坑提醒： 不要只罗列指标名称不讲阈值逻辑，更不要给出“统一阈值” —— 必须体现业务差异（如离线任务与在线服务阈值不同）。
Q2：GC 指标在容量规划中为什么重要？如何设定 GC 告警阈值？
回答框架：
- 影响链路：GC 停顿 → STW → 请求排队 → RT 飙升 → 上游超时重试 → 雪崩
- 关键指标：YoungGC 频率、FullGC 频率、STW 时长（P99）
- 阈值设定：参考 JVM 堆大小与业务容忍度，分级别告警
简短示例回答：
GC 抖动是微服务 RT 波动的首要内因。我通常设定 YoungGC 频率 ≤10 次/分钟，FullGC ≤1 次/小时，STW P99 ≤200ms。FullGC 超 2 次/小时触发严重告警，联动 dump 线程与堆内存快照。
可能追问： “G1 和 CMS 的阈值关注点有什么不同？你用过 Shenandoah 吗？”
⚠️ 避坑提醒： 不要只背阈值数字，要体现 GC 日志分析经验，比如通过 GC 频率反推堆大小是否合理、对象分配速率是否异常。
Q3：连接数指标如何监控？如何避免连接池耗尽？
回答框架：
- 监控维度：活跃连接数、空闲连接数、等待队列长度、超时次数
- 阈值策略：连接池最大值的 75% 告警、90% 严重，等待队列 > 100 触发降级
- 优化措施：连接池隔离、动态扩容、快速失败 + 限流降级
简短示例回答：
监控活跃连接数与等待队列长度，阈值设为连接池最大值的 75% 告警、90% 严重。核心措施：按业务维度拆分连接池（写库 / 读库隔离），配合限流降级与快速失败，防止单连接池耗尽拖垮整个服务。
可能追问： “数据库连接池和微服务间 gRPC 连接池的阈值策略有什么区别？连接泄漏怎么排查？”
⚠️ 避坑提醒： 不要只谈监控不谈 主动防御措施（如连接泄漏检测、自动恢复、优雅关闭），面试官关注的是你能否在生产中真正避免雪崩。
📁 真实项目案例：电商大促微服务容量保障与监控体系建设项目
业务背景
双11 大促期间核心交易链路频繁超时，原有监控只有单机 CPU/内存，缺乏容量规划与分级告警机制，导致多次 P0 事故。
规模指标
200+ 微服务、5000+ 容器实例、峰值 QPS 50 万+、日处理订单 3000 万+
技术栈
Kubernetes · Istio · Prometheus · Grafana · Alertmanager · HPA · Elasticsearch · SkyWalking
核心难点
突发流量下资源争抢导致 RT 飙升、GC 抖动引发连锁故障、数据库连接池耗尽导致雪崩、告警噪声大难以定位根因
面试高频追问
① 大促期间如何快速定位资源瓶颈？
② 监控大盘如何设计以支撑 1-5-10 快反？
③ 告警阈值如何随大促阶段动态调整？
② 监控大盘如何设计以支撑 1-5-10 快反？
③ 告警阈值如何随大促阶段动态调整？
可迁移回答话术
“采用 业务指标 + 资源指标 + 依赖指标 三层监控体系，核心服务预留 30% 冗余容量，HPA 基于 CPU + QPS 双指标自动扩缩容，关键阈值基于历史峰值 ×1.5 倍设定并通过压测持续校准，配合告警静默与分级通知降低噪声。”
💡 本章核心记忆锚点：
✅ 六大指标：CPU · 内存 · 网络 · 磁盘 · GC · 连接数
✅ 阈值公式：
✅ 告警三要素：级别（告警/严重/降级）、通知（电话/钉钉/短信）、自愈（弹性伸缩/重启/降级）
✅ 避坑口诀：不背数字讲逻辑，不谈防御只谈看。
✅ 六大指标：CPU · 内存 · 网络 · 磁盘 · GC · 连接数
✅ 阈值公式：
阈值 = 历史峰值 × 1.5 冗余系数（可动态调整）✅ 告警三要素：级别（告警/严重/降级）、通知（电话/钉钉/短信）、自愈（弹性伸缩/重启/降级）
✅ 避坑口诀：不背数字讲逻辑，不谈防御只谈看。