PromQL实现Actuator获取的JVM指标的Full GC次数监控-Toy模板网

这篇具有很好参考价值的文章主要介绍了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)结束
两者的主要区别在于:

收集的内存区域不同

minor GC 收集新生代内存区域

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

发生频率不同

minor GC 频繁发生,回收高死亡率的短生命周期对象

major GC 间隔时间长,回收长期存活的老对象

消耗时间不同

minor GC 周期短,收集效率高

major GC 周期长,执行效率较低,可能造成停顿

触发条件不同

minor GC 由新生代内存不足触发

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

收集对象不同

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的次数。
具体解释:文章来源地址https://www.toymoban.com/news/detail-646085.html

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

到了这里，关于PromQL实现Actuator获取的JVM指标的Full GC次数监控的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！