Probe is displayed with red color in Health View

Check probe logs and Health View’s “Metric Information”.

Telnet from probe machine to Diagnostics server – port 2612.

Ping from Diagnostics server to probe machine by “registered name”

–Try setting /etc/ registered_hostname=

Telnet to Diagnostics server HTTP port from probe machine.

• Check for Firewalls.

• Check if any proxy specified or needed.

• Try changing /etc/

• Try starting probe with -Dhttp.nonProxyHosts=<fully qualified name of the Diagnostics server>


Probe does not appear in Health View

Check probe logs.

Check /etc/ registrar entry can be resolved and verify probe can ping host specified.

– registrar.url=http://<Diag_server>:2006/commander/registrar/

Verify probe started – (i.e. http://<probe>:35000/).

Telnet from probe to Diagnostics Commander’s HTTP port.

– Check for Firewalls.

– Check if any proxy specified or needed.

– Try starting probe with -Dhttp.nonProxyHosts=<DiagnosticsServerName> ( fully qualified name )

Diagnostics 9.20 support for SQL server version 2012

Diagnostics 9.20 collector cannot access SQL metrics because the column names are different in versions 2010-2012 (compared to 2005-2007).


2012-08-09 12:13:57,371 SEVERE sqlserver_collector [Thread-9] Creation of statistic queries failed for instance [SharePoint:FIDB008:49532] The query run was [SELECT cpu_count, physical_memory_in_bytes, virtual_memory_in_bytes,
GETDATE() date FROM sys.dm_os_sys_info] Invalid column name ‘physical_memory_in_bytes’.

Therefore, SQL server cannot be supported.

In order to fix this error and be able to retrieve data from SQL server 2012, a new patch should be created.

HP has planned to be include it in Diagnostics 9.22 release.

Information about JMS property X_Mercury_Diag_Color added to the MQ message

Messages in MQ have an extra JMS property X_Mercury_Diag_Color added to it when diagnostics is enabled. This will cause issues in message handling components.

HP Diagnostics need the JMS property X_Mercury_Diag_Color to for JMS cross-vm outbound calls and topology. It’s not intended to interfere with the application unless the app monitor the custom JMS property.

It is inserted by the following points’ code snippets.





User can either disable the points entirely, or just the detail section to block the code snippets.

However please note that disabling these points reduces diagnostics functionality, in particular, cross-vm correlations between the applications communication via JMS. Therefore should only disable these as a last work around, AND only disable for the specific probes that send JMS messages to recipients that fail.

A better workaround will be to ignore the JMSMessage properties that are not recognizable in the application. Example: to review/check how the application handles the JMS property, and see if it is possible to change the logic or add a filter to ignore the JMS property X_Mercury_Diag_Color (or to ignore any unknown JMS properties).

Definition of maximum number of unique URI’s

Sometimes, it is necessary to modify the default value of maximum number of unique URIs to be captured by every probe.

If you face any of the below situations:

1. It is necessary to reduce memory consume, default value (1000 URIs) may be reduced.

2. The number of URI’s is not enough for matching user’s needs.

In this case, it is necessary to edit <Diagnostic install>/etc/ file from the probe and modify the below property:

maximum.unique.uris = 1000

Note: It is necessary to consider a higher memory consumption when increasing this value, so archive folder may grow faster.

Issues connectig to Oracle DB in an RAC environment from Diagnostics Collector

If the following error is seen in the Collector Log:

SEVERE oracle_collector [Thread-54] SID:OracleDBServer:1526 Connection Failure: Listener refused the connection with the following error:


The problem occurs because the Oracle DB is in a RAC environment

The problem can be resolved by setting up one probe per instance when working in an RAC environment