PromQL实现Actuator获取的JVM指标的Full GC次数监控

Spring Boot 版本需要2.0.0或更高版本。
添加Micrometer Prometheus registry依赖:

<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

在application.properties中开启prometheus端点:

management.endpoints.web.exposure.include=health,prometheus,metrics

做完上述配置后,Actuator就可以通过Micrometer获取到JVM的GC指标,其中包括:

• jvm_gc_memory_promoted_bytes_total:记录New Generation晋升到Old Generation的内存大小总和。反映对象存活率。
• jvm_gc_max_data_size_bytes:Old Generation的最大内存容量。
• jvm_gc_memory_allocated_bytes_total:累计向堆分配的内存大小。反映内存使用增长趋势。
• jvm_gc_pause_seconds_x:GC暂停时间,可用于记录GC停顿时间和次数。
• jvm_gc_pause_seconds_count ：统计 Young GC 和 Full GC 的暂停次数
• jvm_gc_live_data_size_bytes 表示 JVM 堆内存中存活的数据大小（GC 前老年代的内存使用大小）。
  
  jstat -gc pid查看gc情况
  

end of minor GC 和 end of major GC 都是 JVM 垃圾收集的相关指标,它们分别代表:

• end of minor GC - 小型垃圾收集(Young GC)结束
• end of major GC - 大型垃圾收集(Full GC)结束
  两者的主要区别在于:

1. 收集的内存区域不同

• minor GC 收集新生代内存区域
• major GC 收集新生代和老年代内存区域

2. 发生频率不同

• minor GC 频繁发生,回收高死亡率的短生命周期对象
• major GC 间隔时间长,回收长期存活的老对象

3. 消耗时间不同

• minor GC 周期短,收集效率高
• major GC 周期长,执行效率较低,可能造成停顿

4. 触发条件不同

• minor GC 由新生代内存不足触发
• major GC 由老年代内存不足或元数据触发阈值触发

5. 收集对象不同

• minor GC 主要是无用的短生命周期对象
• major GC 主要是存活时间长的老对象

jvm_gc_pause_seconds_count

jvm_gc_pause_seconds_count是JVM中与GC相关的一个重要指标,它统计了不同类型的GC过程导致程序暂停的次数。
主要通过观察该指标的标签来分析其涵义:

• action:表示GC的不同阶段,例如minor GC开始或结束,major GC开始或结束等
• cause:导致这次GC的原因,例如Allocation Failure(分配内存失败)、Metadata GC Threshold(元数据GC阈值)等

出现full GC则告警

groups:
  - name: jvm.rules
    rules:
      - alert: JVMFullGcCountTooMuchIn1d
        expr: increase(jvm_gc_pause_seconds_count{action="end of major GC"}[1d]) >1
        labels:
          severity: warning
        annotations:
          summary: "一天内full GC次数>1次"
          description: "(env: {{ $labels.env }})应用{{ $labels.application }}一天内full GC次数{{ $value }}次 \n"

这个 PromQL 表达式的意思是:1天内(通过[1d]指定时间范围)Full GC(major GC)结束时(action="end of major GC"过滤条件)的GC 暂停次数(jvm_gc_pause_seconds_count指标)的增加量(increase函数)大于1。也就是检测在1天内,Full GC的增量次数是否大于1。
这可以用于设置一个Full GC次数增长的告警规则:

• 如果1天内Full GC次数的增量超过1,则可能存在问题
• 该表达式作为告警规则的阈值,一旦触发则发送告警
  设置这个规则的目的是快速发现Full GC次数增加的情况,由于Full GC会造成较长时间的应用线程停顿,次数增多可能导致用户体验下降。

# 该表达式不精准，被弃用
groups:
  - name: jvm.rules
    rules:
      - alert: JVMFullGcCountTooMuch
        expr: sum(changes(jvm_gc_live_data_size_bytes[5m])<0.9)by (namespace,application,env)>1
        labels:
          severity: warning
        annotations:
          summary: "full GC次数>1次"
          description: "(env: {{ $labels.env }})应用{{ $labels.application }}full GC次数为{{ $value }}次 \n"

这个 PromQL 表达式的作用是计算最近5分钟内,jvm_gc_live_data_size_bytes 指标变化小于0.9的次数。
具体解释:

1. changes(jvm_gc_live_data_size_bytes[5m]) 计算最近5分钟的存活数据大小的变化比例。
2. changes(jvm_gc_live_data_size_bytes[5m]) < 0.9 表示变化比例小于0.9,即减少超过10%。
3. sum(…) 对上一步的比较结果求和,即统计变化比例小于0.9的次数。
4. sum(…) > 1 表示最近5分钟内,变化幅度超过10%的次数大于1。
   通常老年代内存数据大小的明显下降,意味着发生了 Full GC。
   所以这个表达式的作用就是检测最近5分钟内是否发生过多次 Full GC。
   通过设置不同的时间范围和变化比例阈值,可以根据需要检测 Full GC 情况。
   这个表达式利用了 Prometheus 的聚合查询功能,可以实现对 GC 行为的监控检测。