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/dispatcher.properties registered_hostname=
Telnet to Diagnostics server HTTP port from probe machine.
• Check for Firewalls.
• Check if any proxy specified or needed.
• Try changing /etc/dispatcher.properties force.1.2.event.channel=true
• Try starting probe with -Dhttp.nonProxyHosts=<fully qualified name of the Diagnostics server>
Check probe logs.
Check /etc/dispatcher.properties registrar entry can be resolved and verify probe can ping host specified.
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 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]
com.microsoft.sqlserver.jdbc.SQLServerException: 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.
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).
Diagnostics compares the average value for the metric in the last five minutes to the threshold. Alerting is triggered by comparing the Avg metric value in the last 5 minutes to the threshold. Currently the Avg metric value in the last 10 minutes (or longer ) to the threshold is not supported.
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/capture.properties 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.
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