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.
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!
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.
Top Comments