Workflow Types
In MOM 2005 things were fairly straight forward. You had the concept of rules, tasks and responses. That was really it. There were some more advanced type of rules that carried state change information but this was for a small number of advanced MP authors. In Operations Manager 2007 there are a number of distinct types of workflows that are used for different purposes. Some of these are loaded by the health service on the agent or server and are running continuously while others are loaded on-demand as they are required. A management pack may ship one workflow or thousands of workflows. This section gives you the lowdown on the different types of workflow such as a rule or a task.
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 separate workflow will execute for every object that is present of this type.
Rule
A rule uses data source, condition detection and write action module types in its definition. A rule will be loaded into memory as soon as an object of the type that the rule is targeting is managed by the healthservice. A rule continues to be held in memory waiting for data items to be generated from the specified data source(s). A rule must be formed according to the following flow chart:
A rule consists of one-to-many data source modules, zero or one condition detection module and one to many write action modules. If more than one data source module is used, a condition detection module must be used and the module type of the condition detection module must accept the same number of inputs as the number of data sources present.
Each module in the workflow is defined to be of a particular module type. The module type defines the behavior of the module and may be a code based implementation or a composite of other module types.
Every rule must end in at least one write action that changes the monitored system state or Operations Manager state e.g. raises an alert, stores data in the database.
A rule is typically used for one of three purposes:
Collect data and store it in the Operations database and/or the data warehouse
Generate an alert based on instrumentation observed
Run a timed action on a continuous basis e.g. run a script every five minutes
Discovery
A discovery is a specialized type of rule. A discovery is used solely for the purpose of inserting discovery data into the Operations Manager database. This discovery data may be object instances and/or relationship instances. The workflow for a discovery consists of a single data source:
No condition detection modules or write action module types are allowed. There is an implicit write action for all discoveries that is handled by Operations Manager internally. This write action inserts the discovery data into the database. Operations Manager also handles discovery data caching internally so data is only sent to the management server and database if it has changed from the last execution of the discovery.
The module type that is used for the data source must output System.DiscoveryData in order to be used in a discovery workflow. If you try to use a module type that does not output this type of data, MP Verify will not pass for you management pack.
A discovery for each instance of the object type that the discovery is targeted at is loaded and held in memory waiting for data items to be generated from the specified data source.
Although a discovery can only contain a single data source module, a data source module type can be composed of other modules. For example a scheduler can be composed with a script probe action into a new data source module type. Many of the out-of-the-box data sources that are defined for discovery purposes are composite module type definitions.
Task
A task is a workflow that is not loaded by the health service until it is requested by the user through the Operations Console or some other SDK call. The user executes the task for one or more objects, the agent receives notification from the server to execute the workflow and then output returned to the database. Once the workflow has executed, it is unloaded from memory until it is called again. A task does not have a data source or a condition detection module. It must consist of either a single probe action or a single write action. You should use the correct type of module depending on what your task will do. If it is only reading system state, use a probe action. If it is changing system state in some way, use a write action.
You will recall that probe actions and write actions expect some input data. This is provided for a task in the form of a trigger signal by the health service. As a result you should only use a probe action or write action module type in a task when the type expects System.BaseData or trigger only data. For example if your module type is expecting performance data or event data, it is not going to get this data type when it is launched as a task.
Monitor
A monitor is used in Operations Manager to determine state of a monitored object. Each monitor is a distinct state machine that has a set number of states. A monitor is in a single state at any one time. Aggregate and dependency monitors are specific types of monitors that derive their state from other monitors only. Although these use workflows internally it is not necessary to understand the internals of these types for this discussion. This section focuses on unit monitors only.
A unit monitor is defined to be or a particular monitor type. The monitor type defines the workflows that the monitor will use. Typically a monitor type has a separate workflow for each state that the monitor type declares. In addition on-demand workflows can be defined for each state as well. Therefore when a monitor is created there can be many monitors running for each instance of the monitor.
For regular detection workflows (normally ongoing operation of a monitor) any number of modules can be used. The rules for the workflow are:
The workflow must begin with one or more data source modules
The workflow must not use write action modules
The workflow can use condition detection and probe actions modules in any order
Only one data stream should be outputted i.e. if you are using two data source modules you must pass the output to a condition detection module
For each health state of the monitor, the workflows should be mutually exclusive i.e. data should only be output for one workflow for a given set of instrumentation. Since a monitor is a state machine it is invalid to output both states at a given time. Therefore when you are using an expression filter in your workflows you should make sure both expression cannot evaluate to true at once.
As an example a two state monitor may define the following workflows for regular detection:
State 1:
State 2:
It is possible that one monitor state can declare no workflow for regular detection. This means that this state can only be entered when the user resets the monitor or the monitor is reset by the health service (comes out of maintenance mode or initiates for the first time)
The on-demand workflows for a monitor type define what state will be set when the monitor is reset (by the user, by exiting maintenance mode or on first initialization). These workflows must follow these rules:
The workflow must begin with a probe action
The initial probe action must be trigger only i.e. it takes no input data
The workflow can use condition detection and probe actions modules in any order
No data source or write actions can be used in the workflow
A two state monitor may define the following workflows for on-demand detection:
State 1:
State 2:
As with regular detection you should ensure only one state evaluates at a given time to avoid non deterministic behavior.
Diagnostic
A diagnostic is a specialized type of task. A diagnostic uses a monitor state change to trigger execution. It is either executed on demand by the user (or another SDK call) when a monitor is in a given state or automatically by the health service when the state is entered. Diagnostic workflows are targeted to a type of object, a monitor and a specific health state of the monitor. A diagnostic is not loaded by the health service until it is required.
The diagnostic consists of zero or one condition detection modules and one probe action module. A diagnostic should not change system state in any way.
The condition detection will often be a filter that looks at the input data item (the state change with the original data item that caused the state change as context) and evaluates it against a filter.
Multiple diagnostics can be created for the same monitor state if required.
Recovery
A recovery is another specialized type of task. A recovery uses a monitor state change or diagnostic output to trigger execution. It is either executed on demand by the user (or another SDK call) when a monitor is in a given state or automatically by the health service when the state is entered. Alternatively it may execute only after a specific diagnostic has provided output data. Recovery workflows are either targeted to a type of object, a monitor and a specific health state or they are targeted to a type of object and a specific diagnostic that is targeted to the same type.
The recovery consists of zero or one condition detection modules and one write action module. A recovery changes system state is some way.
The workflow for a recovery triggered by a state change is:
The workflow for a recovery triggered by a diagnostic is:
Comments
Anonymous
January 01, 2003
@Rahul - should be fixed now. Sorry about that - worked in IE9 but not some other browsersAnonymous
January 01, 2003
pictures need work but good blog,Anonymous
March 10, 2011
Picutres are not coming on this page