Cook down is an important concept in MP authoring. This is where it is important to understand basic module and workflow concept. You should make sure you read the module type and workflow type sections first so that you understand this section.
The Operations Manager agent or server is running many hundreds or even thousands of workflows at any given time. Each workflow that is loaded takes some system resource. Obviously the less system resources we take up for monitoring the better. There is a lot the MP author can do to reduce the impact of monitoring on the system. One way to do this is to ensure that you do not target a workflow too generically. For example if you have a rule that is only applicable to servers running Microsoft SQL Server 2005 don’t target the rule at all Windows Servers. Instead you should target it at the appropriate SQL Server class. This is a basic principle and is fairly easy to understand if you ever built a MOM 2005 management pack. In MOM 2005 you would build a computer group and ensure it only included computers that should receive the rules.
However, this section is not about targeting, it is about a concept we call cook down. This is a principle whereby for most modules the Operations Manager health service will try to minimize the number of instances in memory. This is done by considering the configuration of modules. Usually, if the health service sees two modules with the same configuration in different workflows that have the same configuration, it will only execute a single module and feed the output to all the workflows that defined the module.
Consider a simple example:
Rule 1: Collect an event from the application log where Event ID =101 and Event Source = Event Create
Modules:
Rule 2: Collect an event from the application log where Event ID =201 and Event Source = Event Create
Modules:
Operations Manager sees that the event provider data source is configured the same for both rules. Only one instance of the module will run. The two expression filters will take input data from the output of the same module. The workflows effectively become:
In the case of the event log provider, there will only be normally be only one module executing for each log that is being monitored (unless you are running the module under different credentials for different workflows).
Cook down becomes extremely important when you are writing scripts, especially when you have scripts running against multiple instances of an object type on the same health service. If you do not think about cook down, you could end up running many scripts when you could actually run a single script by thinking about configuration and targeting.
I will cover script cook down in detail in the scripting section of this site when I get to it.