Java Database Connectivity SQL Queries Response Monitoring (jdbc_response) probe v1.27 released!

[Ravishu Arora]

Hi All,

We are proud to announce the General Availability of the Java Database Connectivity SQL Queries Response Monitoring (jdbc_response) probe v1.27.

• This release adds a new configuration option that allows a user to associate metric and alarm data generated by the probe to the robot rather than the target system. This is helpful in quickly identifying the root cause when a centralized database is being monitored from multiple locations, using multiple instances of the probe.
• The release also has some updates to maintain the probe's strong security stance.

You can find more details in the Release Notes and the probe is available on the GA Archive at support.nimsoft.com.

------------------------------
Principal Product Manager
Broadcom Software
------------------------------

[Garin Walsh]

Is there any further information about the option to "associate metric and alarm data generated by the probe to the robot rather than the target system"?

There is a hyperlink in the release notes but it does not appear that customers have access to that.

The documentation appears to indicate that you can set this option in the AC probe configuration but that option is not presented. Is there an update to PPM that needs to occur too?

Would be nice to have the name of the new config key added to the release notes along with a bit on actual usage.

[Stephen Danseglio]

This is the section content that the hyperlink references:

'Associate Data and Alarms with Robot':

Select this option to associate the monitoring QoS data and alarms on (should be with...) the Robot instead of the target machine.

------------------------------
Steve Danseglio
Technical Support Engineer 4 | IMS Division
UIM Certified Expert
KCSv6 Practices Certified
Certified Customer Success Manager (CCSM) Level 1
------------------------------

[Garin Walsh]

Thank you - so where's the option?

 

From the documentation, the implication is that it should be here. But it is not.

[Stephen Danseglio]

Its the QOS and Alarm source override.

Steve

------------------------------
Steve Danseglio
Technical Support Engineer 4 | IMS Division
UIM Certified Expert
KCSv6 Practices Certified
Certified Customer Success Manager (CCSM) Level 1
------------------------------

[Garin Walsh]

"Its the QOS and Alarm source override." doesn't seem right - these have been there from at least as far back as 1.26. Would be unusual to be calling them out in much later release notes.

The documentation also mentions them separately:

 

versus

 

But assuming that it is, how to you enable the configuration to include the robot name? There's no $ variable for robot name for instance and the fields for the override are text entry.

Can you perhaps show me a screen shot of what this should look like? 

[Stephen Danseglio]

It was implemented for MCS as well.

"Allow an option for remote monitoring probes to send the robot name as Alarm Source and QOS Source using their respective MCS templates."

Steve

------------------------------
Steve Danseglio
Technical Support Engineer 4 | IMS Division
UIM Certified Expert
KCSv6 Practices Certified
Certified Customer Success Manager (CCSM) Level 1
------------------------------

[Stephen Danseglio]

Hi Garin,

This new feature was specifically added for MCS.

"Allow an option for remote monitoring probes to send the robot name as Alarm Source and QOS Source using their respective MCS templates."

Use case description:

A customer using MCS wanted the QOS and alarms to reflect the robot/source machine where the probe is deployed, e.g., via source override option.

 

For example, two instances of sql_response are running on two different servers monitoring the same target SQL DB but one remote probe instance encounters an issue accessing the database. Both robots/servers need access to monitor the sql DB (from their location/machine). 

 

They may also need a new alarm message to be generated. 

 

They need the alarm to indicate a connection problem from the specific robot/remote probe instance on that robot to the specific target in the case where one instance has an issue with connection to/accessing the DB or throws some error but the DB is not actually having an issue.

 

In this case, the customer is monitoring the same instance of an SQL database from 2 different locations. In case of a problem, all alarms and QoS data are attached to the device where the SQL database is running. That means, that the group responsible for the SQL server is informed (via email or ticket) about an issue. But then would they check and confirm that the database is running fine, and without issues. Then in that case, the ticket has to be reassigned to another group (which has to be figured out first by analyzing what the error is about), e.g., the issue might have been related to network issues, or changed credentials on a specific database.

 

Thus, the customer would like to configure all data (QoS and alarms) are attached to the device where the probe is running. In that case, the groups responsible for Server 1 or Server 2 would be informed about database connection issues. This would speed up the resolution time of issues drastically for the customer, because the correct group would be informed and could trace the issues directly from their end.

When the techdoc is fully updated, I'll send you the url.

Steve

------------------------------
Steve Danseglio
Technical Support Engineer 4 | IMS Division
UIM Certified Expert
KCSv6 Practices Certified
Certified Customer Success Manager (CCSM) Level 1
------------------------------

[Ravishu Arora]

Hi Garin,

It is a simple toggle feature which controls if the data generated (Qos, Alarms) is associated with the target being monitored vs the robot itself.

Please see the screenshot below that shows the 2 step process:

------------------------------
Principal Product Manager
Broadcom Software
------------------------------

[Stephen Danseglio]

Hi Garin, Ravishu,

Ah yes, this option is new and only available in jdbc_response version 1.27.0.

Thanks,

Steve

------------------------------
Steve Danseglio
Technical Support Engineer 4 | IMS Division
UIM Certified Expert
KCSv6 Practices Certified
Certified Customer Success Manager (CCSM) Level 1
------------------------------

[Garin Walsh]

Right, so how do you get this option

to show. 

Mine (with 1.27.0 installed) looks like:

[Stephen Danseglio]

Hi Garin,

Im running jdbc_response 1.27.0 on DX UIM 23.4 CU2.

Here is a screenshot:

------------------------------
Steve Danseglio
Technical Support Engineer 4 | IMS Division
UIM Certified Expert
KCSv6 Practices Certified
Certified Customer Success Manager (CCSM) Level 1
------------------------------

[Garin Walsh]

"Im running jdbc_response 1.27.0 on DX UIM 23.4 CU2." - Me too - hence the whole conversation here I think.

jdbc_respose is on a server running Linux in case that matters.

Otherwise I'll open a support case for this. Sounds like the option is supposed to be there on the page and it's not even though the versions are all the right number.

Wouldn't be the first time with UIM that a piece of functionality needed a reinstall to get it working right. Or some other not quite documented tweak for that matter. Or negative interaction with something else installed already that wasn't considered in testing.

[Stephen Danseglio]

Hi Garin,

What version of Linux?

Steve

------------------------------
Steve Danseglio
Technical Support Engineer 4 | IMS Division
UIM Certified Expert
KCSv6 Practices Certified
Certified Customer Success Manager (CCSM) Level 1
------------------------------

[Jason Allen]

I would try the following (and also perhaps ensure PPM probe on the hub where jdbc_response is under is up to the latest version)

1. Deactivate the ppm probe on that hub.
   2. Clean the files related to the specific probe from the  /probes/services/ppm/cache/ folder
   3. Activate ppm probe.
   4. Verify that a probe specific jar file for the new probe version is created in  /probes/services/ppm/adapterlib folder when opening the GUI

[Garin Walsh]

OK - so for what it's worth to others:

I tried the steps outlined by Jason Allen to no effect. On the Linux system, the cache directory is empty except for one directory which is also empty.

I reinstalled ppm on the Linux system from the local archive (DX UIM 23.4 CU2) and the same behavior is observed.

I installed jdbc_response and PPM on a fresh windows server (under the possibility that this issue is OS specific) and the option is still not presented.

The version of PPM in the archive matches the internet archive but for kicks, I download the internet archive version and import it into the local archive. Get the message that the same version already exists and if I want to overwrite - I note that the build number on the internet archive version is yyMMddHHmm which is a little odd but whatever.

I apply this version to the Linux system and the option is still not presented.

In a final effort, I apply to the newly created windows system and voi la, the option is presented. 

So, there must be some difference between the ppm in the internet archive and ppm included in the CU2 service pack.

So ultimately, the information needed was that the tag in the cfg file was "useRobotAsSource = yes".

As an aside, don't like the use of mixed case in the variable name - that leads to many more opportunities for misspelling the tag. 

[Rajesh Banuka]

Hi Garin,

There is no difference between PPM version in the web archive and the one shipped with 23.4 CU2. I manually verified both of them.

I suspect the issue on Linux environment is due to the presence of old Adapater jar inside ppm\adapterlib folder. Could you please check once, if exists delete and retry probe configuration UI. 

Rgds,

Rajesh B

[Garin Walsh]

Ultimately the issue wound up being twofold - first, the appearance of the new checkbox was being prevented because the new jdbc_response probe was not in the archive local to the hub where PPM was running for this robot. It was in the central archive where AC is running but the actual config page comes from the hub that the robot running the probe is connected to.  

Second, the probe package only includes some of the jars necessary to run the oracle jdbc driver - it was necessary to manually include the jars oraclepki.jar, osdt_cert.jar, and osdt_core.jar in addition.