Java项目开启JMX:Prometheus数据上报

对于Java项目而言,开启JMX 进行JVM监控是很有必要的,可以帮忙开发人员分析、定位问题

常规开启Java JMX 方法

一般可以在启动脚本中添加相关的参数

-Dcom.sun.management.jmxremote.port=6543 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false

上述的配置项,会在指定的端口(比如6543)开启JMX,这样的话像JConsole这样的监视器就可以通过这个端口连接到应用程序。

同时连接不需要身份认证和SSL

关于都有哪些常见的 JMX 监控工具,详见文末小福利

Java spring boot 框架开启JMX

最常见的就是在Java项目的 applicaiton.properties 文件中添加如下配置

spring.jmx.enabled=true

但是现在基本都是使用 spring boot 框架开发,有更简便的方案。

案例中是使用 spring boot 框架 加 apollo 配置中心。所以核心配置都是在Apollo中进行配置。

在Java项目的 applicaiton.properties 文件中进行如下配置加载 Apollo

# 服务ID,对应的Apollo中的服务ID 
app.id=xxxx-service
    
# apollo 相关配置
apollo.cluster=default
# Apollo的访问地址
apollo.meta=http://apollo.xxxx.local
apollo.cacheDir=/data/apollo-config
apollo.bootstrap.enabled = true
apollo.bootstrap.eagerLoad.enabled = true
apollo.bootstrap.namespaces = application,elasticsearch,redis,tech.consul,tech.site,logger,tech.database

Apollo中JMX 相关配置及说明

# apollo中项目对应的application 命名空间
management.endpoint.metrics.enabled = true
management.endpoint.prometheus.enabled = true
management.endpoints.jmx.exposure.include = health,prometheus
management.endpoints.web.exposure.include = health,prometheus

management.metrics.export.prometheus.enabled = true
management.metrics.tags.application = ${spring.application.name}

management.endpoint.health.show-details = ALWAYS
management.health.redis.enabled = false

细心的同学已经发现,在项目的 applicaiton.properties 中没有配置 spring.jmx.enabled=true

那么上述的配置是否真的开启了JMX呢?答案是肯定的,已经开启了。

这是因为:

在SpringBoot中 management.endpoints.jmx.enabled 默认为True,它会自动开启JMX监控功能。

在Spring Boot框架中提供了对JMX的自动配置,当检测到management.endpoints.jmx.enabled属性为true时,会自动开启JMX监控功能,并将MBean注册到MBean服务器中。

因此,即使在应用的配置文件中没有显式地配置 spring.jmx.enabled=true,Spring Boot应用也会开启JMX监控功能。


下面对Apollo中配置的相关参数做详细介绍

  • management.endpoint.metrics.enabled 是用于启用或禁用 Spring Actuator Metrics 端点的参数。

    该端点提供了当前应用程序的度量指标信息,一般是指通过 /actuator/metrics 提供如应用程序的请求量、响应时间、错误率等。

  • management.endpoint.prometheus.enabled 参数是用于启用或禁用 Prometheus 端点的开关。

    当设置为 true 时,Spring Boot 将启动一个 HTTP 服务器,向 /actuator/prometheus 路径提供可供 Prometheus 采集的指标数据。这些指标数据可以用于监控应用程序的性能、健康状态等信息。

  • management.metrics.export.prometheus.enabled 是 Spring Boot Actuator 库提供的一个配置参数,它用于启用或禁用 Prometheus 格式的度量指标的导出。

    默认情况下,该参数的值为 true,即启用 Prometheus 格式的度量指标的导出。

    但是当参数的值为 false 时,应用程序不会将度量指标以 Prometheus 格式导出。

    但是可以通过其他格式的导出方式访问度量指标,如 JSON 或 JMX

  • management.endpoints.jmx.exposure.include 用于指定哪些端点将在 JMX 中暴露出来。

    默认情况下,JMX 中的所有端点都是开启的。可以使用逗号分隔的端点 ID 列表来配置开启哪些端点

  • management.endpoints.web.exposure.include 用于指定哪些端点将在 Web 界面上暴露出来。

    默认情况下,Web 界面上的所有端点都是开启的。同样可以使用逗号分隔的端点 ID 列表来配置开启哪些端点

比如上面种,这两个都只是保留 healthprometheus 两个断点。所以可以请求 /actuator/health/actuator/prometheus 。 虽然 management.endpoint.metrics.enabled = true 开启可以通过 /actuator/metrics 获取数据 , 但是实际上 JMX 或者Web形式都没有进行暴露,所以请求 /actuator/metrics 是 404

  • management.metrics.tags.application

    用于在度量指标中添加标签,这里是添加了一个 application 标签,您可以根据自己需求添加

  • management.endpoint.health.show-details

该参数用于控制是否在/actuator/health 接口中是否展示所有细节,如果请求可以开启,有助于排查问题

  • management.health.redis.enabled

用于控制是否在/actuator/health 接口是否检测该项目链接的所有Redis,如果开启,会检测所有的,如果有一个Redis有问题连接不上,就会导致这个服务的健康检查为 Down 无法注册到Consul ,进而无法对外提供服务。

配置Prometheus

然后在Prometheus中就可以通过服务暴漏的/actuator/prometheus 接口获取服务的性能数据,然后通过grafana进行 监控数据的呈现

# 
- job_name: 'consul-discovery-service'
    scrape_interval: 30s
    metrics_path: '/actuator/prometheus'
    consul_sd_configs:
    - server: 'consul.xxxx.local'
    

因为服务都是注册在 Consul中的,所以通过 consul_sd_configs 的形式可以简化配置

然后在Prometheus自带的Web页面中进行查询

jvm_memory_used_bytes{job="consul-discovery-service"}

结果如下

prometheus-jvm

可以看到采集到了相关的JVM数据,然后进行Grafana配置即可。

网上有合适的JVM模板,自行搜索导入Grafana即可。

小福利

1、常见的 JMX 监控工具:

  • JConsole:Java 自带的监视工具,可通过 JDK 中的 bin 目录下的 jconsole 命令启动,提供了一些基本的监视功能和操作界面。

  • VisualVM:Java 自带的多合一监视和分析工具,集成了 JConsole 和 VisualGC 等插件,提供了更加详细的监视信息和功能。

  • Mission Control:Java 官方提供的高级监视和管理工具,提供了诊断、调优、性能分析等丰富的功能。

  • Zabbix:开源的网络监控和管理工具,支持通过 JMX 监控 Java 应用程序,提供了实时监视、性能分析、告警等功能。

  • Nagios:开源的网络监控和管理工具,可通过插件扩展支持 JMX 监控 Java 应用程序,提供了实时监视、告警等功能。

  • Prometheus:开源的监控和警报工具,可通过 Prometheus 的 JMX exporter 支持 JMX 监控 Java 应用程序,提供了度量和警报功能。

  • Jolokia:开源的 JMX-HTTP 桥接器,可将 JMX 接口转换为 HTTP/JSON 接口,方便其他监视工具集成。

  • JavaMelody:开源的 Java 应用程序性能监视工具,支持通过 JMX 监视 Java 应用程序,提供了实时监视、性能分析等功能。

这些工具中,你了解和熟悉那些呢?

2、在 management.metrics.export 配置下,常见的 reporter 包括:

  • prometheus:用于将度量数据导出到 Prometheus 监控系统。

  • graphite:用于将度量数据导出到 Graphite 监控系统。

  • influx:用于将度量数据导出到 InfluxDB 时间序列数据库。

  • stackdriver:用于将度量数据导出到 Google Cloud Stackdriver。

  • jmx:用于将 JMX bean 度量数据导出到 JMX 管理系统。

  • newrelic:用于将度量数据导出到 New Relic APM 系统。

欢迎关注个人公众号

全栈运维

### Java运维监控服务状态工具推荐 在Java运维领域,为了确保应用程序的稳定性和高效运行,选择合适的监控工具至关重要。以下是几种常用的Java运维监控工具及其特点: #### 1. Zabbix Zabbix 是一种功能强大的开源监控解决方案,支持多种类型的监控需求,包括但不限于网络设备、服务器性能以及应用服务的状态监测[^2]。通过配置 `UserParameter` 和 `JMX Interface`,可以实现对Java应用程序的深入监控。例如,对于Tomcat这样的中间件,可以通过自定义脚本收集其运行指标并上报到Zabbix Server。 ```bash # 配置文件 /etc/zabbix/zabbix_agentd.conf 中添加以下参数 UserParameter=tomcat.status,ps aux | grep tomcat | wc -l ``` 此外,Percona 提供的 MySQL 插件也可以集成至 Zabbix,从而完成数据库层面的健康度评估。 --- #### 2. Prometheus + Grafana Prometheus 是另一种流行的开源监控系统,特别适合微服务架构下的动态环境。它能够抓取目标节点上的时间序列数据,并利用 Pushgateway 或 Exporter 来扩展采集范围。针对 Java 应用程序,可部署专门设计的 JMX Exporter 将 JVM 的内部统计信息暴露出来以便进一步分析[^1]。 配合可视化平台 Grafana 使用,则可以让这些复杂的数值变得更加直观易懂。下面是一个简单的例子展示如何设置 Prometheus 抓取 Tomcat 数据源: ```yaml scrape_configs: - job_name: 'tomcat' static_configs: - targets: ['localhost:9000'] labels: alias: 'production-tomcat-instance' ``` --- #### 3. JPOM (Java Project Operation Management) JPOM 是一款专注于简化 Java 项目操作流程的产品,具备较低的学习成本和较高的灵活性[^5]。相比传统方式需要手动 SSH 登录远程主机才能完成诸如启停进程之类的动作,在采用 JPOM 后只需点击几下鼠标即可达成相同效果——而且这一切都不再依赖于知晓具体机器账户凭证的前提条件之下! 更重要的是,该框架内置了一套完善的权限管理体系,允许管理员根据不同角色分配相应的访问级别,有效降低了因误操作而导致的风险概率。同时由于整个交互过程均基于 Web UI 展开的缘故,所以即使是没有太多经验的新手也能快速上手掌握要领。 --- #### 4. Docker Compose 方案 如果团队已经决定采纳容器化策略来部署业务逻辑的话,那么不妨考虑借助官方文档提到的方法构建专属的监控服务体系[^3]。比如 Kuma 这个项目就提供了现成的模板可以直接拿来即插即用,仅需简单几步就能让集群内的各项资源状况尽收眼底。 执行如下指令便可一键拉起所需组件: ```shell docker-compose up -d ``` 随后可通过浏览器访问指定端口查看实时更新的各项图表展现形式的结果。 --- #### 总结 每种方案都有各自的优势所在,实际选型过程中还需要综合考量当前的技术栈现状以及其他非功能性约束因素的影响程度之后再做定夺。无论是倾向于高度定制化的开发模式还是追求极致简便性的成品路线,上述列举出来的选项都能够很好地满足大部分场景下的基本诉求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值