publish driver cache statistics in cn=monitor

Idea ID 2779097

publish driver cache statistics in cn=monitor

IDM currently publishes ProcessedOperationsCounts in cn=monitor but no information about a driver's cache. When queried via dxcmd for "Get driver cache statistics" IDM return both the ProcessedOperationsCounts along with the age and number of transactions in a driver's cache.
Especially the age of the oldest transaction and the total number of transactions in the cache are vital in determining the health of a driver.
5 Comments
Absent Member.
Absent Member.
@MF; what is the current status of this request?
Micro Focus Expert
Micro Focus Expert
Status changed to: Under Consideration

Under consideration for IGA and analytics in IDI.

Question: If not implemented in cn=monitor but included as part of the overall Analytics story for IDM and IGA, would that suffice?

Knowledge Partner Knowledge Partner
Knowledge Partner

If not in cn=monitor, why have cn=monitor at all? Is that not the place to monitor the processes?  How do you decide which is 'monitor' worthy (Not sponge) and which should be in longer term reporting/storage.  (Which is actually a fair and hard question to answer).

This example though might provide a simple criteria...  cn=monitor would be for things that a alerting/paging/monitoring solution might need.  I.e. Service up/down. Cache filling faster than it is emptying.  Cache is older than X days. 

Whereas, how many PRDs have been run this week makes more sense in a Reporting/IDI style solution.

Micro Focus Expert
Micro Focus Expert
Status changed to: Under Consideration
 
Cadet 3rd Class
Cadet 3rd Class

Our "workaround" solution (using Nagios-invoked dxcmd + XML parsing to get driver cache/backlog info) for alerting on-call personnel is fairly heavy-weight, especially with 30-40 busy drivers on a single IDM server. Uunder heavy load the multiple dxcmd invocations "cost" has actually further negatively impacted our servers at times, so much so that our Nagios script has a "short-circuit" option in it to report "unmonitored" if the dxcmd processes start stacking up...

Having the cache info available in cn=monitor would be way more useful to me than after-the-fact counts of how many modify/add/delete events have already occurred. (We literally never use or track that information at all, but do rely heavily on knowing the age of the oldest entry in each driver's cache.)

It's hard to phrase it better than the original poster plus GeoffC's comment. If I could "thumbs up" their entries, I would!

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.