如何在云原生中监控JVM指标

介绍

尽管 Java 的性能和底层编译型语言没有太大区别&＃xff0c;但您可能仍需要调整&＃xff08;Java 虚拟机&＃xff09;JVM 性能以满足应用程序的需求。在可扩展性和性能方面&＃xff0c;应用程序的需求和要求可能会有所不同&＃xff0c;这时需要持续监控您的 JVM 性能&＃xff08;一些关键指标——内存使用、垃圾收集和线程&＃xff09;&＃xff0c;以相应地对其进行调整。

我们可以通过使用 JMX Exporter 将应用程序 JMX 对象暴露给 Prometheus 并在 Grafana 中创建所需的图表来监控这些指标。为此&＃xff0c;请按照以下步骤操作。

一般 Java 集成 Prometheus 监控指标有两种方式。一种是依赖中引入&＃xff0c;另外一种是通过agent执行。

依赖引入


io.prometheussimpleclient0.15.0


io.prometheussimpleclient_hotspot0.15.0


io.prometheussimpleclient_httpserver0.15.0


io.prometheussimpleclient_pushgateway0.15.0


对于基于 Springboot 开发的 Java 框架&＃xff0c;一定要引入micrometer-registry-prometheus这个依赖&＃xff0c; Spring Boot使用 Micrometer &＃xff0c;一个应用 metrics 组件&＃xff0c;将 actuator metrics 整合到外部监控系统中。

它支持很多种监控系统&＃xff0c;比如Netflix Atalas, AWS Cloudwatch, Datadog, InfluxData, SignalFx, Graphite, Wavefront和Prometheus等。

这时只需要在 application 配置文件中添加如下端口配置&＃xff0c;即可对外暴露 JVM 指标。

management:health:db:enabled: falseserver:port: 8080endpoint:web:exposure:include: &＃39;*&＃39;exclude: envhealth:show-details: alwaysshutdown:enabled: falsemetrics:tags:application: ${spring.application.name}

agent 方式执行

下载 Java JMX Jar https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.15.0/jmx_prometheus_javaagent-0.15.0.jar并将下载的 .jar 文件放在类路径中&＃xff0c;具体路径可以自己设计&＃xff0c;比如打到镜像特定路径下&＃xff0c;或者放到 tomcat 服务指定路径下。

为您的应用程序配置 Config.yaml 文件

将 Jar 作为 Java 代理运行

java $JAVA_OPTS -javaagent:./jmx_prometheus_javaagent-0.13.0.jar&＃61;8080:config.yaml -Xlog:gc&＃61;debug:file&＃61;gc.txt -DApp.config.file&＃61;application.properties -cp "orderauditservice.jar: *” org.springframework.boot.loader.JarLauncher

具体如何采集除 JVM 之外的指标&＃xff0c;请参考&＃xff1a;https://github.com/prometheus/client_java

访问指标

现在可以通过http://localhost:8080/metrics访问指标

grafana可配置指标

使用 Prometheus 指标准备示例 Grafana 仪表盘&＃xff0c;我们可以获取到已经抓取到的指标&＃xff0c; springboot 提供了如下指标可用于grafana展示使用。

• JVM

1. jvm.memory.max JVM最大内存

2. jvm.memory.committed JVM可用内存 是 展示并监控堆内存和Metaspace 重要

3. jvm.memory.used JVM已用内存 是 展示并监控堆内存和Metaspace 重要

4. jvm.buffer.memory.used JVM缓冲区已用内存

5. jvm.buffer.count 当前缓冲区数

6. jvm.threads.daemon JVM守护线程数 是 显示在监控页面

7. jvm.threads.live JVM当前活跃线程数 是 显示在监控页面&＃xff1b;监控达到阈值时报警

8. jvm.threads.peak JVM峰值线程数 是 显示在监控页面

9. jvm.classes.loaded 加载classes数

10. jvm.classes.unloaded 未加载的classes数

11. jvm.gc.memory.allocated GC时&＃xff0c;年轻代分配的内存空间

12. jvm.gc.memory.promoted GC时&＃xff0c;老年代分配的内存空间

13. jvm.gc.max.data.size GC时&＃xff0c;老年代的最大内存空间

14. jvm.gc.live.data.size FullGC时&＃xff0c;老年代的内存空间

15. jvm.gc.pause GC耗时 是 显示在监控页面

• TOMCAT

1. tomcat.sessions.created tomcat已创建session数

2. tomcat.sessions.expired tomcat已过期session数

3. tomcat.sessions.active.current tomcat活跃session数

4. tomcat.sessions.active.max tomcat最多活跃session数 是 显示在监控页面&＃xff0c;超过阈值可报警或者进行动态扩容 重要

5. tomcat.sessions.alive.max.second tomcat最多活跃session数持续时间

6. tomcat.sessions.rejected 超过session最大配置后&＃xff0c;拒绝的session个数 是 显示在监控页面&＃xff0c;方便分析问题

7. tomcat.global.error 错误总数 是 显示在监控页面&＃xff0c;方便分析问题

8. tomcat.global.sent 发送的字节数

9. tomcat.global.request.max request最长时间

10. tomcat.global.request 全局request次数和时间

11. tomcat.global.received 全局received次数和时间

12. tomcat.servlet.request servlet的请求次数和时间

13. tomcat.servlet.error servlet发生错误总数

14. tomcat.servlet.request.max servlet请求最长时间

15. tomcat.threads.busy tomcat繁忙线程 是 显示在监控页面&＃xff0c;据此检查是否有线程夯住

16. tomcat.threads.current tomcat当前线程数&＃xff08;包括守护线程&＃xff09; 是 显示在监控页面 重要

17. tomcat.threads.config.max tomcat配置的线程最大数 是 显示在监控页面 重要

18. tomcat.cache.access tomcat读取缓存次数

19. tomcat.cache.hit tomcat缓存命中次数

• CPU

1. system.cpu.count CPU数量

2. system.load.average.1m load average 是 超过阈值报警 重要

3. system.cpu.usage 系统CPU使用率

4. process.cpu.usage 当前进程CPU使用率 是 超过阈值报警

5. http.server.requests http请求调用情况 是 显示10个请求量最大&＃xff0c;耗时最长的URL&＃xff1b;统计非200的请求量 重要

6. process.uptime 应用已运行时间 是 显示在监控页面

7. process.files.max 允许最大句柄数 是 配合当前打开句柄数使用

8. process.start.time 应用启动时间点 是 显示在监控页面

9. process.files.open 当前打开句柄数 是 监控文件句柄使用率&＃xff0c;超过阈值后报警 重要

堆内存监控

在上图中&＃xff0c;您可以看到平均堆使用量、最大堆使用量和最大分配堆内存&＃xff0c; 如果您在特定时间观察到堆内存使用量突然激增&＃xff0c;您可以将应用程序响应时间与请求数量相关联&＃xff0c;并检查峰值是否是由于请求增加或代码自身问题导致。

GC监控

在上图中&＃xff0c;您可以看到 min GC Count、max GC Count、min GC Time 和 max GC Time。GC 运行的频率&＃xff0c;每次 GC 花费的时间。因此&＃xff0c;当 GC 发生过于频繁或收集未引用对象所花费的时间太长时&＃xff0c;它会影响您的应用程序的性能。这也可能是内存泄漏的另一个迹象&＃xff0c;或者它可能只是意味着应用程序需要更多的堆空间。

Thread 监控

线程始终处于任何应用程序的中心阶段。线程负责服务用户请求。有足够的空闲线程来接受所有用户请求是很重要的。如果您没有足够的线程&＃xff0c;这将增加用户请求的等待时间&＃xff0c;进而增加应用程序响应时间。当线程需要较长时间来完成用户请求时&＃xff0c;它会将引用的对象在堆内存中保存较长时间。这反过来会影响内存空间&＃xff0c;并可能导致 OOM 或 GC 问题。

在上图中&＃xff0c;您可以看到 Live、Demon 和 Deadlocked 线程数。

在上图中&＃xff0c;您可以看到 Blocked、Waiting 和 Timed Waiting 线程计数。

总结

虽然框架已经为我们提供了各种指标&＃xff0c;但是配置关键指标的使用仍然是一个复杂的过程&＃xff0c;找出那些指标表明正在运行的应用程序的运行状况和性能&＃xff0c;并在使用过程中不断优化和调整。

推荐

使用 Promethues 监控的一些实践

顶级的Kubernetes日志监控工具

原创不易&＃xff0c;随手关注或者”在看“&＃xff0c;诚挚感谢&＃xff01;