Micro Focus Diagnostics helps to quickly isolate and resolve development and production app performance issues by providing code-level visibility at the transaction level.
This post will have the monthly Micro Focus Diagnostics Tips and Tricks which will be a consolidation of various common issues in Micro Focus Diagnostics. Do check out this article for troubleshooting tips and tricks for other tools.
Micro Focus Diagnostics – Tips and Tricks – Jan 2021
1. Retrieving the samples from the Diagnostics Collector Agent in case there is a failure
It often happens that the users are not able to get the samples from their respective Diagnostic Agent. They have encountered access and permission related problems. And there is an error on the screen, with all of the credentials given below:
2020-01-16 11: 22: 00,426 WARN user admin [shared InfrequentEventScheduler] Failing permissions download from http://HPDIAGNOSTIC.uanl.red:2006 java.net.ConnectException: Connection timed out: connect (URL: http://HPDIAGNOSTIC.uanl.red:2006/webPasswordAuth/permissions?username=mercury&probegroup=Default) 2020-01-16 11: 22: 00,426 WARN user admin [shared InfrequentEventScheduler] RerunValidation (Permissions): Unable to contact commander. Keeping Revalidate permissions for user mercury in group probegroup = Default (lastaccess 66938ms ago) 2020-01-16 11: 22: 01,960 WARN useradmin [RangeSocketListener-1] No recent communications with Diagnostics Server (http://HPDIAGNOSTIC.uanl.red:2006) - not attempting remote user authentication / authorization (remote users will be denied access)
This error can be fixed as well; you just need to follow the steps given below carefully:
- You need to navigate to Maintenance, then under that, click on Registrar.
- Then you need to click on the Registered components; then, you need to find the Nexus_BD.
These steps will guide you to cancel the registration, and you just need to wait for some time so that it can register again to inform metrics one more time. This solution should be effective, and it will solve all the authentication-related errors that occurred before.
It is also recommended that the user checks the proxy server settings that the users can find on the Mediator server. The Mediator server is located in the /etc/server.properties file and, then on the Commander server under the path similar to the /etc/ file.
2. Instructions to tackle the Diagnostics .net Agent ProbeAggregator when it goes out of Java heap size
This issue is experienced when the Diagnostics 9.50 and .net agent 9.50 are installed in the Windows Operating System server 2012 platform. Users encounter this issue when they notice that the .Net agent is unable to collect any of the necessary data.
When the log details are checked, an error says, “java.lang.OutOfMemoryError: Java heap space” on the ProbeAggregatorJSW.log file the user is currently running on the device. The root cause of this error is the java.lang.OutOfMemoryError factor of the respective file.
This error can be easily solved manually; the user just needs to follow the steps given below:
- Open probeaggregator.cmd, taking the help of the notepad.
- Then increase the -Xmx value to a higher one.
For example, it could be two times higher than the previous value or as per the system resources requirement.
3. Details regarding the configuration of the Diagnostic server
Figuring out how to configure the Diagnostic server on your own may seem like a difficult task, but the users can do it with the help of certain guidance. Many users have faced an error in the Performance center Diagnostic scenario page.
It is observed that it usually happens when they are working on the settings icon. The error message that is being displayed is given below:
Unable to configure J2EE/.NET Diagnostics. There may be a configuration problem with the Diagnostics Server Details specified in the Diagnostics page of the Administration Site.
This error can be fixed, but before that, the user needs to have full information about the product that has been installed and about its version too. As per the application technology you are using, you will have to install a Java or .NET agent.
Along with that, the specific instrument of that application should be obtained too because it will be responsible for sending data to your Diagnostics server. The user needs to make sure that the particular Diagnostics server version is not a lower kind than any of the Diagnostics agents.
4. Removing the Oracle Java JRE 1.8.x / 8.x from C:\Program Files (x86)\
It has often been observed that the Diagnostics server 9.26 Oracle Java JRE 1.8.x / 8.x creates problems while working. The users have some complaints, while they currently have 2 of the Diagnostics servers.
Both are running an older version 9.26, the users want to delete the previous Oracle Java files but are afraid if that would affect the Diagnostics application in any way.
The answer to that query is that removing the previous Oracle Java JRE 1.8.x / 8.x from C:\Program Files (x86)\ files would not affect the Diagnostics application’s functioning.
Once you have finished removing the Oracle Java JRE 1.8.x / 8.x from C:\Program Files (x86)\ files, you just need to navigate to the Diagnostics server’s embedded JRE.
At the time of the installation, the JRE comes with the Diagnostics server in the embedded form, so deleting Oracle Java JRE 1.8.x / 8.x from C:\Program Files (x86)\ would not be a problem.
5. Viewing the Hikari connection Pool JMX parameters
Users often have problems regarding the Hikari connection Pool JMX parameters, as they cannot view it to inspect it or keep an eye on it. There is also an issue regarding the configuration of the metrics.config file at all times.
It is observed that the team that utilizes the said application needs to monitor the activities of the JMX parameters. While using the Hikari connection pool, the team wants to monitor all of the information related to Hikari, like its object name, class name, and all of the descriptions that come along with it.
The users also observe that in the metric.config file for the Java agent 9.51 there are some Hikari metrics(these metric.config file lines between the range of 358 and 365) present. You can find the metrics.config file in the Java platform section by the set definitions given below:
P120?Java\ Platform/com.zaxxer.hikari\:name\=dataSource,type\=HikariDataSource,*.MaximumPoolSize = Maximum Pool Size count Hikari P120?Java\ Platform/metrics\:name\=HikariPool-1.pool.ConnectionCreation,*.Count = Current Count count Hikari
6. Fixing the issue when the Diagnostics only collects one server request for Open Text
It often happens that the users have an issue in the server request collection in the Diagnostics. The Diagnostics seem to collect only one server request for the Open Text. The specific server request that it collects is a get() statement. Diagnostics, which is 184.108.40.206 on the Windows Server 2016 standard.
Users already have installed the .NET agent that comes along with the Diagnostics 9.50 generally. The OpenText server is responsible for running the Windows Server 2012 R2.OpenText usually uses IIS to deliver content.
The user is recommended to utilize the custom instrumentation initially for safety purposes. In the beginning, we could run on the Diagnostics server 9.4x, or we can also navigate to the suitable .dll files that are applicable. This is necessary to establish a secure platform for monitoring as per the requirement of Diagnostics.
In order to instrument the Java side, the user needs to use the Java agent. Then they need to carefully check the documentation and remain updated about it so that they can instrument the JVM with ease.
It is necessary for acquiring more detailed information regarding OpenText. It is also important that their support/R&D are directly contacted in order to obtain the documentation or some direct instruction that points to the major .NET DLL(s) that needs to be instrumented.
7. Specification of Multiple JBoss targets possible and providing support for Java Agent Scripts
Users often have queries regarding the multiple target specification for Diagnostics Java Agent installations for Tomcat or JBoss monitoring, if it is supported for Java Agent Scripts or not.
They have observed that at the addition of the specific configuration lines for JBoss, it puts special characters in it, and the manual is seen to have only the UNIX/Linux items that are mixed with the Windows variables, like $JAVA_HOME vs. %JAVA_HOME%.
It is observed that it is copying and pasting this same information, basically just results in the special characters being inserted in the standalone.bat. Thus, it becomes worrisome, and that is the reason for the application’s service for behaving unnaturally. Similarly, a plain text version for the one given following would be appropriate for this problem, for the Windows version:
if $cygwin; then JBOSS_HOME=`cygpath --path --windows "$JBOSS_HOME"` JAVA_LOC=`cygpath --path --windows "$JAVA_LOC"` JBOSS_CLASSPATH=`cygpath --path --windows "$JBOSS_CLASSPATH"` JBOSS_ENDORSED_DIRS=`cygpath --path --windows "$JBOSS_ENDORSED_DIRS"` fi # Configuring Diagnostics Java Agent AGENT_HOME= PROBE_ID= "$JAVA" -jar $AGENT_HOME/lib/jreinstrumenter.jar -f $PROBE_ID PROBE_OPTS="-Xbootclasspath/p:$AGENT_HOME/classes/$PROBE_ID/instr.jre" PROBE_OPTS="$PROBE_OPTS -javaagent:$AGENT_HOME/lib/probeagent.jar" PROBE_OPTS="$PROBE_OPTS -Dprobe.id=$PROBE_ID" # Use the line below ONLY for JBoss 6 # PROBE_OPTS="$PROBE_OPTS - Djava.util.logging.manager=org.jboss.logmanager.LogManager" # Use the line below ONLY for JBoss 7 PROBE_OPTS="$PROBE_OPTS - Djboss.modules.system.pkgs=org.jboss.byteman,com.mercury.opal" JAVA_OPTS="$JAVA_OPTS $PROBE_OPTS" # Display our environmentecho "=========================================================================" echo "" echo " JBoss Bootstrap Environment" echo "" echo " JBOSS_HOME: $JBOSS_HOME"Thank you.~ Michael
This issue can be fixed while we are working on JBoss 7 JVM. In the specific version of JBoss 7, the domain server has a domain.xml file; the following section was added to each of the Server-group element-
Here the problems are being analyzed that occurred following the install documentation, and that enables us to find the solution for the same as well:
- It was noted that the non-primary nodes were not able to load the agent; it was because the Diagnostics Agent path is specifically unique on each server. The same server-group settings are usually passed to every server in the said cluster. This can be fixed with the use of a wildcard that is located in the section above; it starts with Xbootclasspath.
- Then in the monitoring console, it is noticed that the probes were not visible properly, and users found it difficult to continue. The issue remained the same even while using the %0 variable in the Probe.id, which made it difficult to view and introspect which of the server and JVM the user was actually looking at in the console. This issue can be solved by simply passing an environment variable, that is $VIPNAME into the xml, with the JVM name. Kindly note that the JVM name is also the server-group name.
In the second section mentioned above, it is observed that the probe.id is actually the application name and VIP, which makes it pretty clear for the user to identify which JVM is being monitored using the console. With the help of this naming method, the user can also add as many servers or JVMs as they require, and it will be accurately shown in the console from now on.
8. Upgrading the Diagnostics server 9.50 and retaining the configuration settings and the historical data
Users often come across difficulties while upgrading the Diagnostics server 9.50 to the most recent version, 9.51. The users want to retain the configuration settings and the historical data while keeping the Diagnostics server version 9.50 and then importing the applications from the previous version. It is also observed that upgrading to the 9.51 version has resulted in absolute failure.
It is quite possible to upgrade to 9.51 from the previous version of the 9.50 Diagnostics server while keeping the configuration settings and the historical data. For keeping the said changes from the previous versions and upgrading the Diagnostics server, the user can simply to follow the steps given below carefully:
- You need to stop the earlier version and end-all of the processes of Diagnostics 9.50.
- Then you need to make sure to back up the /etc folder anywhere outside the Diagnostic server, so it is not lost in the procedure.
- Then you must backup the /archive folder outside the Diagnostics server.
- Then you need to completely uninstall Diagnostics 9.50.
- Now you need to install Diagnostics 9.51 completely.
- After that, you must stop Diagnostics 9.51 services.
- Then replace the /etc. and the /archive folders present with the backups from steps 2 and 3 above.
- Now start the Diagnostics 9.51 services manually.
9. Instructions to instrument Oracle Application without needing a console (CPE OCTIM19G1061847)
The users have installed a Diagnostics agent on the Oracle app server successfully. The problem arises when the Application Server Control console is not activated or enabled. Due to that problem, users are unable to follow up on the procedure as duly mentioned in the Diagnostics Java guide.
It is indeed possible to add the JVM parameters on your own, without needing any of the Application Server Control console. The application server version which the EBS currently utilizes is 10.1.3.5.
The user can generally perform this procedure without a console, you just need to instrument the core module. After that you will need to add them to the start Java options section accordingly:
data id="java-options" value=" -server -verbose:gc -Xmx512M -Xms128M -XX:MaxPermSize=160M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+UseTLAB -XX:+UseParallelGC -XX:ParallelGCThreads=2 -Dcom.sun.management.jmxremote -Djava.security.policy=$ORACLE_HOME/j2ee/oacore/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false -Doracle.security.jazn.config=/backup/oracle/TSAP01/inst/apps/TSAP01_slwerpd01/ora/10.1.3/j2ee/oacore/config/jazn.xml -Dhttp.cookie.ignoreCommaInCookiesNamed=X_NoMatchingCookies"/>
10. Solving the error when the Diagnostic Java Agent fails to reflect after the restart using GUI
The users often go through errors when they restart Diagnostic Java Agent while using the Node Manager in GUI. The error is regarding the Diagnostic Java Agent when it does not react or reflect after restarting.
The situation is that it barely only reflects when the application team starts the script again manually. It may seem bothersome if this is a recurrent problem. They are noticing that the Application startup through the Node Manager in GUI could not reflect the application data level at all.
This error can be solved if the user takes certain necessary measures. When the user initiates the startWeblogic.sh, that specific agent reflects all of the data of the application. Then the user needs to inspect thoroughly throughout all of the information at hand.
Then they will be able to locate the Node Manager and find that it is using a different script for starting the Diagnostic Java agent. Due to this particular reason, the user had gone through the error because of this particular script that was not compatible hence resulted in this error.
- The user needs to carefully set the StartEnabledScript and check if the files are correct and not corrupted.
- Then they need to make the Node Manager using the start Weblogic.sh script to start the application again.
- Then the users need to make sure that the procedure has been followed seriously, in case there is any follow-up on the screen.