Micro Focus Diagnostics – Tips and Tricks

Table of Contents

Micro Focus Diagnostics – Tips and Tricks – May 2021

1. How to set up BSM / SHA to collect Diagnostics metrics?

A brief intro, BSM stands for Business Service Monitoring and SHA stands for Service Health Analyzer. This is an end-to-end management software tool that joins in a server application, network, and other business transaction monitoring. SHA and diagnostics integration are interrelated to each other.

Now comes the question, how to set up BSM/SHA for collecting Diagnostics metrics? (SHA and Diagnostics integration)

Solution

Step 1: Run this command, \<HPBSMInstalldirectory>\dbverify\bin\run_schema_upgrade.bat.

Step 2: Go to the Windows taskbar, Click Start > All Programs > Business Service Manager > Administration > Configure Business Service Management.

Step 3: Click Next and add an SHA license

Step 4: Click Next and choose Service Health Analyzer

Step 5: Broad the wizard.

Lastly, take a look at this document attached, for more information.

2. How to set up SSL on a Diagnostics server using a certificate from the CA authority?

Want to set up HTTPS through a CA certificate? Check the solution below to know how to set up SSL using a certificate from the CA authority on a Diagnostics server.

Solution

Before jumping into any sol, know-how Keystore and certificates work in Java.

Java’s storehouse for keys and certificates is called a Keystore file. The native tool for managing Keystore files is known as keytool. The keytool comes together in any Java Runtime Environment (JRE).

The Keystore consists of all imported and trusted certificates for retiring HTTPS connections and their public keys. But most critically, it has a SERVER certificate and the unique private key is used for generating that certificate to serve the incoming HTTPS connections.

If a Keystore is created by keytool, there are two options available for SERVER certificate:

Option 1:

Generate the file using a private key. Then, a self-signed certificate will be generated from it. More instructions on this option can be found in the Diagnostics Install and Configure Guide.

Option 2:

First, generate the file with a private key and then generate a certificate request file (.csr) that contains the key for CA authority for creating the certificate based on that key. Once the certificate is made by the CA authority, it is required to import to the Keystore file that contains the matching private key for SSL for working in the SERVER. For implementing this option follow the generic keytool instructions:

Generate keystore:

<diagnostics_server_install_dir>/_jvm/bin/keytool -genkey –keystore <diagnostics_server_install_dir>/etc/keystore -storepass <password> -alias SERVER -keyalg RSA -keypass <password> -dname “CN=<diagnostics_server_hostname>, OU=Diagnostics, O=Hewlett-Packard, L=Palo Alto, S=CA, C=USA” -validity 3650

Produce Certificate request file:

keytool -certreq -alias SERVER -file <diagnostics_server_install_dir>/etc/diag.csr -keystore

<diagnostics_server_install_dir>/etc/keystore -storepass <password>

Appeal to the CA authority for generating certificates using diag.csr file and send back it in .cer format.

Ship in cert.cer certificate file from CA authority in server’s keystore:

keytool -import -trustcacerts -alias SERVER -file cert.cer –keystore <diagnostics_server_install_dir>/etc/keystore

Now, the certificate file must be sent back in the correct Keystore file form in which the certificate request file was created, for public key (in the certificate) and private key (Keystore) matching accordingly. Or else SSL will not work. In the next step, restart the Diagnostics server for picking up the new Keystore file.

But what if your CA authority has already created the certificate through a different private key? Then, follow a different set of instructions for generating the Keystore with matching keys as mentioned below.

To generate Keystore files from existing certificates and private key files follow the below-mentioned steps.

Step 1: Request your CA to send the private key files and certificate files in any form that is supported by OpenSSL binaries. For instance, cert.cer and private.key in PEM format. (If OpenSSL binaries are not available there are many other tools available such as sslshopper.com > ssl converter.html)

Step 2: After receiving the file use OpenSSL for exporting them into pkcs12 format. If possible, request this format from CA authority for skipping OpenSSL export operation:

openssl pkcs12 -export -in cert.cer -inkey private.key -certfile cert.cer -name “SERVER” -out keystore.p12

Step 3: Now, when prompted enter the wanted password for new. P12. You can use the same password for the Keystore file.

Step 4: When .p12 file is created, use keytool for generating the new keystore with matching key:

keytool -importkeystore -srckeystore keystore.p12 -srcstoretype pkcs12 -destkeystore <diagnostics_server_install_dir>/etc/keystore

Step 5: Now enter your password for the new Keystore file as asked by keytool.

Step 6: After the generation of Keystore is completed follow the instructions below to cloud passwords. Set up SSL options in <diagnostics_server_install_dir>/etc/security.properties file as shown in Install & Configuration Guide:

# passwords for the Keystore and key

keyStorePassword=<password used by keytool when Keystore was created>

keyPassword=<private key password used in OpenSSL command>

Step 7: Restart the Diagnostics server for picking up the new Keystore file.

3. JVMJ9VM015W Initialization error for library j9gc23(2): Failed to instantiate heap. 2G requested. Could not create the Java virtual machine

With probe instrumentation and Xmx 2048M, Websphere Application Server fails using 32-bit Jre. But what is the possible issue of Websphere Application Server’s failure? It errors out by showing the message “JVMJ9VM015W Initialization error for library j9gc23(2): Failed to instantiate heap. 2G requested. Could not create the Java virtual machine”

Solution

To fix this troubling issue, check this sol. The max heap should be defined as less -Xmx1500m for 32-bit Jre. For more detailed information, go to oracle.com > tech network > java > hotspot faq 138619.html#gc_heap_32bit

4. JBoss server will not start after probe instrumentation

After Java Probe Instrumentation, the JBoss application server fails to start. Facing this issue? The sol is just below.

Solution

JBoss entails additional special settings for working properly with the Java HP agent.

For JBoss 7.x, 8.x (Wildfly), add the following JVM parameter:

Djboss.modules.system.pkgs=org.jboss.byteman,com.mercury.opal

For JBoss 6.x, add the following JVM parameter:

-Djava.util.logging.manager=org.jboss.logmanager.LogManager

5. Error: “When the timeout occurred the thread…” reported by a Linux based Java application running in a VMware environment with HP Diagnostics

You might observe poor application performance while using the Java Agent to probe a Java application; if it runs on a Linux hosted VMware environment. Another reason for poor performance is if the VMware API provides timestamp info that is not configured correctly.

Want to know detailed information about the issue? If a Java application runs on a Linux server (virtual machine) in a VMware environment that is probed using the HP Diagnostics Java Agent, then the exhibiting performance is poor. 

It also reports the below mentioned in the Java application’s logs:

[7/8/15 15:56:57:847 BST] 0000006c TimeoutManage I WTRN0124I: When the timeout occurred the thread with which the transaction is, or was most recently, associated was Thread[WebContainer: 253,5, main].

When the timeout occurred, the stack of this thread was as follows:

com.mercury.diagnostics.capture.jni.VmwareJNI.getHostTimestampUsecsWa(Native Method)

com.mercury.opal.util.VmwareTimer.getTimestamp(VmwareTimer.java:63)

com.mercury.diagnostics.capture.time.NativeTimer.getTimestamp(NativeTimer.java:81)

com.mercury.opal.util.Timestamp.timestamp(Timestamp.java:434)

com.mercury.opal.capture.util.ThLocalContext.timestamp(ThLocalContext.java:563)

com.mercury.opal.capture.BasicMethodCaptureAgent.beforeInvocation(BasicMethodCaptureAgent.java:159)

com.mercury.opal.capture.proxy.MethodCaptureProxy.beforeInvocation(MethodCaptureProxy.java:78)

com.mercury.opal.capture.proxy.MethodCaptureProxy.beforeInvocation(MethodCaptureProxy.java:131)

org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java)

org.hibernate.engine.CascadingAction$1.cascade(CascadingAction.java:134)

org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:213)

org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:157)

org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:108)

org.hibernate.engine.Cascade.cascade(Cascade.java:248

The performance will no longer be there when the Java Agent is disabled.

Now, let’s move to the reason. When the HP Diagnostics Java Agent finds out that the Java application is probed and being running in a virtual host, like in a VMware environment, the Java Agent by default will try to access VMware for obtaining the timestamp information It is necessary for regulating the latency of functions which is instrumented by the probe.

Moreover, whether the VMware environment doesn’t conform to the requirement specified in the section “Time Synchronization for Probes Running on VMware” present in the HP Diagnostics Installation and Configuration Guide, then the Java Agent accessing the VMware API might exhibit the performance issues.

Solution

For fixing, instruct the Java Agent for using the Java Virtual Machine (JVM). It will help in obtaining the timestamp information rather than the VMware API. Specify a value of “false” for the property “attempt.VMware.timestamp.adjustments” in the Java agent configuration file “capture.properties”.

For instance, edit the file at:

<Java Agent Install>\etc\capture.properties

Then, shape the property “attempt.vmware.timestamp.adjustments” as follows:

attempt.vmware.timestamp.adjustments=false

6. What’s New in 9.23 IP2?

IP2 stands for Internet Protocol Integration Project. But what is new in 9.23 IP2.

Solution

Security Fixes –

It provides an update that fixes the Heartbleed vulnerability issue, which is associated with OpenSSL. For information, check out the HP Security Bulletin and heartbleed.com.

System Requirements Changes –

For the Diagnostics Enterprise UI client, support JRE version 8.

Compatibility Changes –

For implementing more compatibility changes, support the following:

Supports Performance Center version 12.00

Supports LoadRunner version 12.00

RUM-Diagnostics Integration –

Using the .NET Agent, many improvements have been made to the RUM-Diagnostics by injecting in the RUM JavaScript. Want to know more details?

7. How to change Commander to Mediator?

Want to change the Commander to Mediator? If yes, continue to read, you will answer your question. But then pops another question. What is the method for changing a commander to a mediator?

Solution

Here is the solution to change Commander to Mediator. Follow the steps below:

Step 1: Edit the server.properties file. Then, change the ‘commander.url’ value to the valid commander’s address despite the ‘localhost’.

Step 2: Restart the new Mediator.

8. The Diagnostics .NET Agent installation fails when the optional Probe Aggregator Service is selected

If you select optional Probe Aggregator Service, the installation of Diagnostics .NET Agent fails. Why? Security restrictions might cause hinders with the installation of the .NET Agent.

Want to know more about the problem? Let me explain that to you. While struggling to install the Diagnostics .NET Agent, the installation process completes failing; as the optional Probe Aggregator Service is selected on the Windows Server platform.

The subsequent error gets reported in the “ProbeAggregator/log/ProbeAggregator/JSW” file:

FATAL | wrapper | 2014/04/18 16:54:03 | OpenSCManager failed – Access is denied. (0x5)

The error mentioned below might be also found in the “/setup/SetupResults” file has:

Running command: C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\bin\ProbeAggregator-windows-x86-64.exe -i “C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\etc\ProbeAggregatorJSW.conf”

Error message: . Error number: 1

Probe Aggregator setup failed.

Removing temporary setup files folder: C:\MercuryDiagnostics\.NET Probe\setup\pasetupfile

Solution

The main reason behind this error is the security restrictions. Keeping in mind, the fix is here. While installing the .NET Agent with the Probe Aggregator Service, confirm the following:

The User Account Control (UAC) is disabled.

The user carrying out the installation is a well-experienced administrator.

The installer must be launched via the right-click “Run as administrator…” option.

9. How to disable RUM client monitoring on both .Net and J2EE Agent

Do you know you disable the X-HP-CAM-COLOR response header for RUM requests?

But the issue is how to disable the RUM response header (or client monitoring integration) in both J2EE and .Net Agent. Don’t worry, the solution is just below.

Solution

For .Net Probe –

For disabling response header edit the following,

.Net Probe’s etc/probe_config.xml file

And, the key will look something like this in below:

<rum enabled=”true” encryptedkey=”OBF:3pe941vx43903wre40303xxz3q6r42ob43n93wre3io03xjs40h940pc3wir3q233jur3zir3yi03zir3vc03wre3xpi3r8o3olr44na3zor3v6m3vc03zir44u03ohb3rdi3xjs3wx03v6m3zor3yc63zor3jqz3q6r3wd740vi40b53xpi3ike3wx043gp42ur3q233y3r3zwy3wx0432i42293p9p” responseheader=”X-HP-CAM-COLOR”/>

Don’t want to use the above method?

Then, simply set rum enabled=”false” and restart the app server (IIS).

For J2EE Probe –

To fix the Java problem, there is an option available during the installation time. A dialogue box says that “Diagnostics with RUM Client monitor”. After the completion of installation, choose the only way of turning it off, that is, to edit etc/dynamic properties:

html.cm.enable = false

client.monitoring.enabled = false

After completing all the above procedures, the changes will take immediate action.

10. The diagnostics server is registered to another BSM

The error message, “Diagnostics server is registered to another BSM” appears on the screen when integrating diagnostics and Business Service Management (BSM).

Wondering what the problem is? It is simple as the error message itself explains, the diagnostics server is listed as an alternative BSM. The cause of this error is, the setting “bac.registration.use.referer = true”.

Solution

To fix this error, tail the following steps.

Step 1: Open the Diagnostics Commanding Server.

Step 2: Next open MercuryDiagnostics\Server\etc\webserver.properties

Step 3: Change the above line to the property: bac.registration.use.referer = false

Step 4: Restart the commander.