I would like to extend the JDBC sensor pack to include a custom class. I could create a custom sensor pack but it wouldn't be aware that it's a database connection. The class is cognos which we require a great deal of database performance details for.
I have read other posts relaying that it is ill-advised to modify a OOTB sensor pack. Is there a way to enagage to have something added to a sensor pack?
Hello @April L.,
I have had some cases, where the customer needs to exclude a class because they are dynamically created during program execution, modify the out of the box sensor packs.
This goes for inclusions as well. I had a case where a customer used MariaDB instead of MySQL and had different connection classes, and adding the appropriate class to the OOB sensor pack was the recommended path. @April L., this is a support case I opened with a client, where the resolution was to modify the out of the box sensor packs.
the ticket you are referring to is for JMS. That is the only case where modifying the OOTB sensor is required to achieve linking between purepaths.
In April's case, modifying the JDBC sensor will not achieve anything that a normal sensor wouldn't do.
The OOTB sensor packs do more than just tracking classes and this is why adding new entries won't achieve anything.
April, what information are you trying to retrieve from this class?
The class is used to create JDBC connections. As it's not one of the classes listed in the Sensor pack it's not picked up and we don't see the database connections. Were I to instrument the class and methods they would appear as method calls not as database calls, hence the question on if I can modify the sensor pack to include this additional class.
April, As Florent mentioned you cannot modify the JDBC sensor and have additional methods show up as database methods. There's more to the JDBC sensor than just class.method pattern matching.
I would recommend a RFC to include the cognos classes, assuming this might be something other cognos users might be interested in this level of detail. But in the meantime your best bet is to add a custom rule as mentioned above, and capture any appropriate method arguments/return values for additional context as necessary.
Given the method of interest is a database connection method, it seems Invocation Count, Response TIme, and DB name would be the useful metrics. A simple custom sensor can certainly capture the first two, and depending on how the driver is written, you might easily also capture the DB name. If DB name can't be captured when the connection is initiated, perhaps you can capture that contextual string in an earlier method so you still have the unique context in the purepath right before the getConnection().
I had thought that would be the case, I just wanted to confirm for this particular OOTB pack.
We are setting up the custom sensors for the methods however that doesn't populate the database reports with information and this is a database heavy application.
I will raise the RFC for it. Thanks.
From what I have been told custom sensor packs won't do all the extra stuff that the OOTB Database sensor packs will and will treat the calls as method calls rather than Database, so they won't show up as database metrics.