生产环境JVM告警需围绕真实风险场景设计，堆内存持续高位（90%以上3分钟）、GC频次与时长、老年代/Metaspace异常增长、阻塞线程及死锁等指标均需配置可验证、可响应的告警逻辑与自动处置动作。
生产环境 JVM 告警不是“设个阈值就完事”，而是围绕真实风险场景，用可验证、可响应的指标组合来触发动作。重点不在数量多，而在每条告警背后有明确的处置路径。
堆内存使用率：盯住“持续高位”而非瞬时峰值
只看单次 >85% 没意义，容易误报。真正危险的是连续 3 分钟以上维持在 90% 以上，说明对象回收不及时或存在泄漏苗头。
- 告警表达式：
(jvm_memory_used_bytes{area="heap"} / jvm_memory_max_bytes{area="heap"}) > 0.9 - 持续时间设为 3m（不是 1m），避免 GC 波动干扰
- 告警级别设为 critical，并自动触发 dump 分析脚本（如调用 jmap 或配置 -XX:+HeapDumpOnOutOfMemoryError）
GC 行为：区分 Young GC 和 Full GC 的告警逻辑
Young GC 频繁说明分配速率高或 Survivor 区太小；Full GC 频繁则大概率是老年代压力过大或内存泄漏。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- Young GC 告警：
rate(jvm_gc_pause_seconds_count{action="end of minor GC"}[5m]) > 10，持续 2 分钟触发 warning - Full GC 告警：
rate(jvm_gc_pause_seconds_count{action="end of major GC"}[5m]) > 2，立即触发 critical - 单次 GC 耗时超限：
max by(job, instance)(jvm_gc_pause_seconds_max{action=~"end of.*GC"}) > 2（单位秒），说明 STW 时间过长，影响可用性
老年代与 Metaspace：关注“只增不减”的异常趋势
这两类指标不能只看绝对值，更要识别缓慢但持续上升的曲线——这是内存泄漏最典型的信号。
立即学习“Java免费学习笔记（深入）”；
- 老年代使用量 10 分钟内增长 >15% 且无回落：
delta(jvm_memory_used_bytes{area="old"}[10m]) > 15 * 1024 * 1024 - Metaspace 使用率 >95% 并持续上涨：
(jvm_memory_used_bytes{area="metaspace"} / jvm_memory_max_bytes{area="metaspace"}) > 0.95，同时rate(jvm_memory_used_bytes{area="metaspace"}[5m]) > 0 - 配套动作：告警时自动采集
jstat -gc <pid>和jcmd <pid> VM.native_memory summary快照
线程与死锁：对“阻塞态”和“零响应”零容忍
线程问题往往比内存更隐蔽，但爆发更快。阻塞线程数超过阈值或检测到死锁，必须立即干预。
- 阻塞线程数 ≥10 且持续 1 分钟：
jvm_threads_states_current{state="blocked"} > 10 - 死锁检测：Prometheus 本身不直接暴露死锁指标，需配合 Actuator 的
/actuator/threaddump端点 + 自定义 exporter，或用 jstack 定时扫描输出含deadlock关键字的日志行 - 线程总数突增（如 5 分钟内增长 200%）：
delta(jvm_threads_live_current[5m]) / jvm_threads_live_current offset 5m * 100 > 200
