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:
·
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.
·
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:
·
$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.
·
$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.
·
$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.
·
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.)