Java 进程 snmp 监控报告 Eden 和 Survivor Space 的最大值为零
Java process snmp monitoring reports max values for Eden and Survivor Space are zero
我正在通过 Linux 框中的 SNMP 端口（配置 com.sun.management.snmp 属性）监视 WildFly 10.1。0.Final Java 进程。
问题是 Eden 和 Survivor 空间报告的 max 值为零。
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.4 = Counter64: 775946240
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.10.4 = Counter64: 3946840064
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.12.4 = Counter64: 3774873600
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.13.4 = Counter64: 0
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.5 = Counter64: 4194304
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.10.5 = Counter64: 0
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.12.5 = Counter64: 4194304
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.13.5 = Counter64: 0
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.2 = STRING: "Metaspace"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.3 = STRING: "Compressed Class Space"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.4 = STRING: "G1 Eden Space"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.5 = STRING: "G1 Survivor Space"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.6 = STRING: "G1 Old Gen"
许多其他 Java 进程中使用了相同的监控脚本，这些进程未报告此问题。
是什么原因造成的？
这些值可以为零吗？
此致
这里的问题是 jvmMemPoolMaxSize (OID .1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.13) 在 JVM-MANAGEMENT-MIB 中定义为类型 JvmUnsigned64TC，这看起来有点奇怪，因为 Java特别禁止使用无符号整数类型。
jvmMemPoolMaxSize 的描述意味着它代表 java.lang.management.MemoryPoolMXBean.getUsage().getMax() 返回的值。该方法的 documentation 表示“如果未定义最大内存大小，则此方法 returns -1。”
jvmMgmMIB 的描述通过以下解释解决了问题：
Where the Java programming language API uses long, or int,
the MIB often uses the corresponding unsigned quantity -
which is closer to the object semantics.
In those cases, it often happens that the -1 value that might
be used by the API to indicate an unknown/unimplemented
value cannot be used. Instead the MIB uses the value 0, which
stricly speaking cannot be distinguished from a valid value.
In many cases however, a running system will have non-zero
values, so using 0 instead of -1 to indicate an unknown
quantity does not lose any functionality.
我认为可以肯定地说这是零无效的情况之一，因此您应该将其理解为没有定义的最大值。
我正在通过 Linux 框中的 SNMP 端口（配置 com.sun.management.snmp 属性）监视 WildFly 10.1。0.Final Java 进程。
问题是 Eden 和 Survivor 空间报告的 max 值为零。
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.4 = Counter64: 775946240
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.10.4 = Counter64: 3946840064
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.12.4 = Counter64: 3774873600
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.13.4 = Counter64: 0
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.5 = Counter64: 4194304
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.10.5 = Counter64: 0
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.12.5 = Counter64: 4194304
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.13.5 = Counter64: 0
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.2 = STRING: "Metaspace"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.3 = STRING: "Compressed Class Space"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.4 = STRING: "G1 Eden Space"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.5 = STRING: "G1 Survivor Space"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.6 = STRING: "G1 Old Gen"
许多其他 Java 进程中使用了相同的监控脚本，这些进程未报告此问题。
是什么原因造成的？ 这些值可以为零吗？
此致
这里的问题是 jvmMemPoolMaxSize (OID .1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.13) 在 JVM-MANAGEMENT-MIB 中定义为类型 JvmUnsigned64TC，这看起来有点奇怪，因为 Java特别禁止使用无符号整数类型。
jvmMemPoolMaxSize 的描述意味着它代表 java.lang.management.MemoryPoolMXBean.getUsage().getMax() 返回的值。该方法的 documentation 表示“如果未定义最大内存大小，则此方法 returns -1。”
jvmMgmMIB 的描述通过以下解释解决了问题：
Where the Java programming language API uses long, or int, the MIB often uses the corresponding unsigned quantity - which is closer to the object semantics.
In those cases, it often happens that the -1 value that might be used by the API to indicate an unknown/unimplemented value cannot be used. Instead the MIB uses the value 0, which stricly speaking cannot be distinguished from a valid value. In many cases however, a running system will have non-zero values, so using 0 instead of -1 to indicate an unknown quantity does not lose any functionality.
我认为可以肯定地说这是零无效的情况之一，因此您应该将其理解为没有定义的最大值。