The Operations Manager agent or server is capable of running many hundreds, or even thousands, of workflows at any given time. These workflows are defined in management packs as mechanisms that run on a system to provide monitoring and health data; for example, discoveries, monitors, and rules and all workflows. In a typical customer environment, where multiple management packs are being used at one time to monitor all applications in an environment, the result is that many workflows are running simultaneously.
Each workflow that is loaded utilizes a small portion of system resources. For optimal performance of Operations Manager, the fewer system resources that are taken up for monitoring, the better. As a management pack author, it is important to consider minimizing the usage of system resources by your individual management pack to create an optimal experience for customers using your management pack.
One of the most impactful ways to reduce to usage of system resources by your management pack is through cookdown. Cookdown is a concept in Operations Manager which consolidates workflows that use the same configuration. By consolidating workflows, fewer workflows are launched at once, and fewer resources are used to run, for example, a single workflow as opposed to fifty distinct workflows.
So, how does the Operations Manager agent (or server) cook down workflows? In order to understand this concept, we need to know about workflow basics:
<![if !supportLists]> · <![endif]> The building blocks of Operations Manager workflows are module types. A module type can either be a code implementation (native or managed), in which case it is called a unit module. Or it can be a composite of other module types.
<![if !supportLists]> · <![endif]> There are different types of workflows available in Operations Manager, such as rules, discoveries and unit monitors. Every workflow in Operations Manager is targeted at a type of object or a class. The workflow will only be run where an object of this type has been discovered and is being managed by Operations Manager. A separateworkflow will be executed for every instance that is present of this type. This means that if there are fifty instances of class A, a workflow targeted at class A will run fifty times.
Cookdown is a principle where the Operations Manager health service will try to minimize the number of instances of modules in memory at any given time, provided that it is able to do so. Configuration of modules is looked at, and if two workflows use a module with the same configuration, the health service will attempt to execute the module only once, and feed its output into both workflows.
The agent expands every workflow to unit modules (code implementation modules). This means that all composite modules are substituted with the set of module of which they consist. Upon such substitution, the configuration of the workflow that was initially passed to composite modules,is passed from these composite module to the individual unit modules. This is done via $Config/...$expressions. If a module has such an expression, it means it defines a parameter, and the parent module or workflow should pass some value to it to populate this parameter.
At this point, the agent now has a chain of unit modules with corresponding configurations. It then creates a copy of this chain of modules for every targeted object, since a workflow will be run for every targeted object. Since there is now a target for every chain of modules, the agent substitutes all $Target/...$expressions with the corresponding values for each particular target in the configuration for each unit module.
The agent will now try to cook these chains of modules down; the algorithm used follows. The agent analyzes the first unit module in all chains. If it finds chains for which their first modules have the same configuration (i.e. XML representation is exactly the same), it cooks it down. This means that the agent will execute this unit module only once, and feed its results to next modules in the appropriate chains. So, for instance, if a workflow consists of 4 unit modules, and the first 3 of these are identical to the first 3 unit modules in anotherworkflows, the agent will execute these three modules only once (and execute the rest of the modules individually for every workflow).
Here is an example of the impact of workflows that are not properly cooked down: Suppose that we have a Rule targeted to some type (Class A) and there are 100 objects of type Class A on some computer. In this case, the Operations Manager agent will create 100 workflows for this rule. Now suppose that this rule uses script-based module executed every 5 minutes. This means we have 100 scripts running simultaneously every 5 minutes. This will clearly be a critical performance issues.
Here is a properly cooked down example: Let us go back to the same Rule targeted to Class A, where there are 100 instances of Class A. Suppose this rule uses 4 unit modules – a Scheduler, a Script Executer, a Condition Detection and a Write Action. The scheduler, the first unit module, does not take parameters, so it is the same for all 100 workflows. This means that the agent cooks the Scheduler module down.
Then suppose a script takes an expression such as $Target/Property[Type="Windows!Microsoft.Windows.LogicalDevice"]/DeviceID$ and this expression is different for every LogicalDevice instance. This means that the configuration for this module is different for every chain. Thus, the agent will not be able to cook down the Script Executer module and will execute it 100 times.
Let us look at the rest of the modules more closely to find potential for cookdown. Suppose that the second module, the Script Executer, executes a WMI query such as "Select * from Win32_LogicalDisk where ID = DeviceID", determines something, and returns a property bag with one property: "State". The Condition Detection module then checks whether this property "State" contains "BAD". Finally, the Write Action module generates an alert that this logical disk is in critical state.
In order to cook down the Script Executer, we need to make it exactlythe same for all chains (i.e. for all objects). It means that the script must not take parameter “$Target/ Property[Type="Windows!Microsoft.Windows.LogicalDevice"]/DeviceID$.” Is this possible? Yes! The script might execute the WMI query "Select * from Win32_LogicalDisk" and return a set of property bags with two parameters: "DeviceID" and "State". The Condition Detection module will then filter out all unnecessary property bags by comparing $Target/Property[Type="Windows!Microsoft.Windows.LogicalDevice"]/DeviceID$ with the value of "DeviceID" property.
So, what did we do? We moved the object-specific expression from the Script Executer module to the next module, the Condition Detection module, and allowed the agent to cook down the script.
Now, let us go through some expressions which may affect the cookdown process:
<![if !supportLists]> · <![endif]> $Data\...$ expressions don't break cookdown. If the previous module is cooked down, the $Data\...$expression will be same anyways, so they are safe to use.
<![if !supportLists]> · <![endif]> $Config\...$ expressions are substituted by the agent to actual values, and they do not affect the cookdown process. For all chain of modules, such expressions will be substituted with the same values. There is, however, one exception here: if this parameter is overrideable, and there are different overrides for different objects, it will then lead to different chains of modules for individual objects.
<![if !supportLists]> · <![endif]> $Target\...$ expressions cannot be evaluated by this tool; however, they are flagged as a possibility for cookdown. They may be cooked down for workflows targeting the same object. However, across different objects, they are likely to break cookdown unless the referred property is the same for different target instances.
<![if !supportLists]> · <![endif]> Suppose that we have two identical rules (only their IDs are different). In this case, all expressions are substituted with same values between these two rules, and the agent actually executes only one workflow! The exception to this is if there are $MPElement$and $MPElement\Id$in the configuration. In this case, since IDs for the two rules are different, the configuration of the resulting chain of modules for each will also be different, and the agent will not be able to cook down these two rules into one. (NOTE: This cookdown-breaking criteriais not caught by the MP Cookdown Analyzer.)