Very few management packs implement on demand detections for monitors. On demand detections are the semantics by which the “Recalculate Health” or “Reset Health” actions work.
Alas the two cannot be implemented together, I can have a single on demand (and in this case I can use Reset Health) *or* multiple on demands (one for every possible monitor state, so two or three) and in this case I can have a “Recalculate Health”. More over for On Demand Detections cookdown doesn’t work. So for every single monitor target all the on demand detections are run. Bad, very bad. How much?
Take into account this example, you need to monitor 100 sql databases on a single SQL Instance. You want to have a three state monitor for, let’s say, locks count on every single DB. It is possible to write a monitor targeted at each DB (100) that runs just once for SQL instance. In a single run the monitor returns the data items for all the databases and then via filtering every single instance state is evaluated. This can be achieved thanks to the cookdown logic built into the HealthService process. But if you want to have on demand detections for the same monitor, you’ll find your data provider (let’s say a script) is going to be run number of db instances (100) * number of on demand detections (3) or 300 cscript.exe processes run at once.
Bad design that makes on demand detections very dangerous. You must consider on demand detections are run at every monitor initialization, so when the MP is deployed, the monitor is modified by an override, the agent exits maintenance mode, etc., etc. not just when the user hits the recalculate button. I hope it will be fixed in R2 (stay tuned it will be one of the first things I’ll try once RC will be out).
This posting is provided "AS IS" with no warranties, and confers no rights.