Module Type Semantics

This is a quick summary of the different module types available in Operations Manager.  Again nothing new here just cataloging the old content from my site so it is easy to find here.

Operations Manager uses modules to define workflows. Workflows are defined in management packs and distributed to agents and servers via the Operations Manager channel. Workflows can do many things such as collect information and store in the operations database or data warehouse, run timed scripts, create alerts, run on-demand tasks etc. Workflows are defined using modules and modules are defined to be of a particular type known as a module type. A module type can either be a code implementation (native or managed) or a composite of other module types. There are four different module types that can be defined. Each of these has different semantics.

Data Source

A data source module type generates data using some form of instrumentation of some timed trigger action. For example a data source may provide events from a specific Windows event log or it could poll Windows performance counters every 10 minutes for a specific performance counter. There are many data sources available in Operations Manager.

A data source takes no input data and provides one output data stream. The module type will normally require some configuration to specify the behavior e.g. computer name and log name in the case of the Windows event log data source. The module can be represented as follows:

Probe Action

A probe action module type uses some input data to provide some output data and will usually require some configuration to specify the behavior. A probe action will interrogate a monitored entity in some way but it should not affect system state in any way. An example would be running a script that used an application API to generate some data or querying WMI to get some data. Often a probe action will be used in conjunction with a scheduler data source to run some action on a timed basis. The probe action module type may or may not use the input data item to affect the behavior. If the data item is not used the input data should be defined as trigger only. An incoming data item will trigger the probe to execute but the data is not used. Sometimes the data may be used for example if the probe is triggered by a Windows event, it may be required to pass the event ID to the probe action as configuration. A probe action can be represented as:

A probe action provides a single output data stream.

You should note that Operations Manager cannot determine if the probe action is being used to change system state in some way e.g. if you run a script defined using a probe action module type, you could be changing state in some way in your script. It is up to the MP author to adhere to the module type definition guidance. If you are changing system state you should use a write action module type instead.

Condition Detection

A condition detection module type is used to filter the incoming data in some way. There are many types of filter possible e.g. a simple filter on the input data, consolidation of like data items, correlation between multiple inputs, averaging and optimization of performance data etc. A condition detection module type can take one or more input data streams and provides a single output data steam. It can be represented as follows:

Many of the data sources that ship out of the box will already contain an expression filter in their composite definition so it may not be necessary to use a condition detection module in your workflow definitions.

Write Action

A write action module type takes a single input data stream and uses this in conjunction with some configuration to affected system state in some way. This change could be in the monitored system or in Operations Manager itself. For example this may be to run a script that changes something, write data into the Operations manager database or generate an alert. A write action can be represented as:

A write action may or may not output data. This data cannot be passed to any other module because the write action is the last module in a workflow. However, the data may be sent to the Operations database. An example is running a command that outputs data to standard out. This data may be useful to the operator that executed the command and is returned to them and stored as task output.