您的位置: 首页  >  文章  >  基于jmx_api采集jvm遇到坑

基于jmx_api采集jvm遇到坑

分类: 文章 • 2024-06-30 12:28:40

        it里本没有坑，一不小心掉进去了，坑就出来了。这次是由于自已的不懂，才掉进去了。

        在测试环境和线上一样的配置，却出现有的数据采集不到情况，请看下图
基于jmx_api采集jvm遇到坑
 
基于jmx_api采集jvm遇到坑
  我采用的架构方式是：zabbix3.0+java_gateway_jmx。开始填坑debug之旅行。

  1.最开始以为是配置的key出错，一一核对，两个环境的配置都一样的。排除

  2.debug zabbix的所有信息，extended debugging (produces even more information)，没有收获。排除

  3.debug  java_gate的log,没收获。排除

  4.debug  服务器的jmx，还是没收攻。

  5.下了cmdline-jmx....jar，进行debug,下载的地址是：

      http://dldx.****.net/fd.php?i=996982995519160&s=6b88543944aebc3b8a18d3b92109edac

 用法是：Usage: java -jar cmdline-jmxclient.jar USER:PASS HOST:PORT [BEAN] [COMMAND]

  cmdline-jmx这种方也没提供多少有用的信息，返回信息如下

   Usage: Usage (type=javax.management.openmbean.CompositeData)

 PeakUsage: PeakUsage (type=javax.management.openmbean.CompositeData)

 MemoryManagerNames: MemoryManagerNames (type=[Ljava.lang.String;)

 UsageThreshold: UsageThreshold (type=long)

 UsageThresholdExceeded: UsageThresholdExceeded (type=boolean)

 UsageThresholdCount: UsageThresholdCount (type=long)

 UsageThresholdSupported: UsageThresholdSupported (type=boolean)

 CollectionUsageThreshold: CollectionUsageThreshold (type=long)

 CollectionUsageThresholdExceeded: CollectionUsageThresholdExceeded (type=boolean)

 CollectionUsageThresholdCount: CollectionUsageThresholdCount (type=long)

 CollectionUsage: CollectionUsage (type=javax.management.openmbean.CompositeData)

 CollectionUsageThresholdSupported: CollectionUsageThresholdSupported (type=boolean)

 Valid: Valid (type=boolean)

 Name: Name (type=java.lang.String)

 Type: Type (type=java.lang.String)

 ObjectName: ObjectName (type=javax.management.ObjectName)

Operations:

 resetPeakUsage: resetPeakUsage

  Parameters 0, return type=void

  做到这里之后，发现在哪里都正确，因为没找到错误，也许潜得太深了。

6.开始怀疑javae的工作的进程数是否开得过少，默认是5,于是把这两个参数

      StartPollers=40

      StartJavaPollers=40

       重启－－－－没效果

7.整个流程下来，都没有发现明显的异常。最讨厌的就是这些情况

部分错误

没有明显异常，error

google一圈没发现好的建议。

于是低头思看图...........举头望窗外.............

8.最后采取对这两个环境参数的更进一步比对。由于某些原因，就不贴出来了。成功往往来自于细节。经过各种测试排除之后，终于发现启动的时候，gc的机制不一样，测试用的是UseParallelOldGC

线上用的是CMSScavengeBeforeRemark

发现这两个不同，于是改变key写法，果真，有关gc的值采集到，然后联想到old gen的值也采集到了。

突然想明白了，采用gc机制的不同，key的参数不一样，也会影响到对jvm中新生代，持久代，老年代信息采集。

多么伤痛的领悟。

UseParallelOldGC的写法

java.lang:type=GarbageCollector,name= ParNew","CollectionCount"

 

  CMSScavengeBeforeRemark的写法

        java.lang:type=GarbageCollector,name=ConcurrentMarkSweep","CollectionCount“

总结：

为什么会踩到坑。

对jvm整个流程一知半解，gc机制不深入

对key的写法，不熟悉，这方面在google搜一圈和jdk官网上，没发现很全很详细的jmx_api

忽略某些细节

最后来一张大图，虽还没做完，不过问题已经定位出来了


基于jmx_api采集jvm遇到坑
 

 

相关推荐