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!

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!