Troubleshooting
Firewall configuration checking
If the TCP outbound policy for the WhaTap data collection server has not been set, monitoring data cannot be transferred. Deselect the firewall blocking.
Use the telnet command to check "Connected to IP."
$ telnet 52.193.60.176 6600
Trying 52.193.60.176...
Connected to 52.193.60.176.
Escape character is '^]'.
For the connection server details, select a desired project in WhaTap Monitoring Service, and then check in Management > Agent Installation.
SpringBoot 2.2 or later, Tomcat JMX off
If the embedded Tomcat is used in SpringBoot 2.2 or later, the JMX functions do not work with the default settings. In this case, activate the JMX functions. Related link
spring.jmx.enabled=true
server.tomcat.mbeanregistry.enabled=true # tomcat embedded인 경우 #
spring:
jmx:
enabled: true
server:
tomcat:
mbeanregistry:
enabled: true #tomcat embedded
In case of the application server using the OSGI framework
Register any agent package prefix (whatap) in the JVM options for an OSGI framework-based application server.
The application server is available in Jboss EAP 6.0 or later, Jboss AS 7.0 or later, Wildfly 8.0 or later, IBM WebSphere AS 7.0 or later, and such.
JBoss AS, Wildfly, JBoss EAP 6.0 or later
Register a prefix in the following file:
-Djboss.modules.system.pkgs=whatap
WebSphere
As an JVM option, add the following.
-Dcom.ibm.ws.classloader.server.alwaysAllowedPackages=whatap
- If "*" is specified as the default value, no additional setting is required.
- For the setting location, see WebSphere.
Add the security.policy role as follows:
grant codeBase "file:$WHATAP_HOME/-"
{
permission java.security.AllPermission;
};
Errors of Log Manager
If any Log Manager error occurs in JBoss AS 7.0 or later and JBoss EAP 6.0 or later, add the JVM options.
- Set the package name of Log Manager in
-Djava.util.logging.manager. - Set the JBoss Log Manager JAR file in
-Xbootclassloader.
# Specify the exact Java VM executable to use.
#
if [ "x$JBOSS_MODULES_SYSTEM_PKGS" = "x" ]; then
JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,org.jboss.logmanager,whatap"
fi
...
# Specify options to pass to the Java VM.
#
if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-Xms1303m -Xmx1303m -Djava.net.preferIPv4Stack=true"
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/p:/home/vagrant/EAP-7.0.0/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.3.Final-redhat-1.jar"
else
echo "JAVA_OPTS already set in environment; overriding default settings with values: $JAVA_OPTS"
fi
In case the MBeanServerBuilder error occurs
If any MBeanServerBuilder-related error is output in JBoss 5.0 or earlier, add the JVM options.
# Specify options to pass to the Java VM.
#
if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000"
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
fi
In case of occurrence of a permission error
If any Java security policy-related error occurs, add the role setting in $JAVA_HOME/jre/lib/security/java.policy.
To apply all roles collectively, add the setting in java.policy as follows:
grant {
permission java.security.AllPermission;
};
In case of occurrence of the java.io.FilePermission error
Add the setting in java.policy.
grant {
...
permission java.io.FilePermission {package path seen in the error message}, "read"
};
In case of occurrence of the java.util.PropertyPermission error
Add the setting in java.policy.
grant {
...
permission java.util.PropertyPermission {package path see in the error message}, "read"
};
In case the sigar library cannot be loaded
Check whether the execution role for $WHATAP_HOME/lib1/*.so exists. If no permission, give the execution role.
$ sudo chmod +x *.so
If under $WHATAP_HOME/lib1 of AIX 7, libsigar-ppc64-aix-7.so does not exist and the error occurs, copy the file.
$ cp libsigar-ppc64-aix-5.so libsigar-ppc64-aix-7.so
In case CPU metrics are displayed as -1
When running IBM Java in the environment with the latest version of the Java agent, the CPU metrics may sometimes be displayed as -1. This issue occurs because the System Load Average value is not supported on specific platforms.
The Java agent basically uses the Java Management Extensions (JMX) to collect metrics. It uses the getSystemLoadAverage() method of the OperatingSystemMXBean interface. This method returns the average load of the system over the last minute depending on the operating system. However, some platforms do not support this value and may return -1.
The getSystemLoadAverage() method can be checked in the OpenJDK source code. For example, the source code for the OpenJDK 7u version can be seen in the GitHub repository.
Recommendation: Configure metric collection via built-in libraries.
To resolve the CPU metrics displayed as -1, enable the built-in library (OSHI or SIGAR) via the Java agent settings.
-
Java 8 or later: Use the OSHI library.
You can use the OSHI library to reliably collect operating system level metrics. See the following how to configure the agent.
whatap.conf# default false
oshi_enabled=true -
Below Java 8: Use the SIGAR library.
For environments below Java 8, you can collect metrics via the SIGAR library. For more information on how to configure the agent, see the following.
whatap.conf# default false
sigar_enabled=true
-
The OSHI (
oshi_enabled) and SIGAR (sigar_enabled) options are disabled by default. They must be explicitly set if needed. -
Be careful not to enable both settings at the same time. Select a library that best suits your environment and then configure it.