First part: https://maxcoreblog.com/2020/07/23/implementing-scom-managed-modules-part-1/

Second part: https://maxcoreblog.com/2020/08/05/implementing-scom-managed-modules-part-2/

Multiple Instances.

In the past examples, the rules and the monitors target a class, which has singular instance per SCOM Agent. In other words (under usual circumstances), one SCOM Agent monitors single Windows Computer. The next experiment aiming to answer another question: how many instances of a managed module SCOM Agent will create, if the module is a member of rule/monitor targeting a class with multiple instances at the same SCOM Agent. For example logical disks. There can be many of them. So, if our rule targets logical disk, the local computer has three of them, which means, that local SCOM Agent monitors all three instances of logical disk. How many instances of our managed modules SCOM Agent will create? I bet it will be one instance if configuration of all rules/monitors is identical (yes, just like in the past examples, regardless of multiple monitored instances). But, say, if we pass logical disk ID (name, etc.) as a parameter, this will make configuration of the modules unique, and make SCOM create multiple instances. But, it’s just a guess, thus the experiment has to reveal real answer.

For this experiment, I made a complete copy of SimpleWConfigProbeAction class, and make just a few changes: class renamed to DiskProbeAction, log file name renames accordingly, and the only configuration parameter renamed to DiskID. Otherwise, all the code is the same. I won’t be creating a parameter-less class for this experiment — the parameterized class with empty parameter value will suit for the purpose.

So, after creating the DiskProbeAction class, I do the usual wrappings in management pack XML code, and create same set of a rule and a monitor (but not a task). Note, in this case, I didn’t make the DiskID parameter overridable. This is because it intended to be set automatically from target class’ instance property, therefore, it could break the whole mechanic, if an operator can change it. Therefore configuration XML fragment looks the following:

        <Configuration>
          <xsd:element minOccurs="1" name="DiskID" type="xsd:string" />
        </Configuration>
        <OverrideableParameters />

For the first part of this experiment, I set disk ID empty, so the empty configuration for the rule and monitor will look like:

<Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <DiskID></DiskID>
</Configuration>

After deploying the new management pack version, let’s check the output log. In this log, the second square brackets contain disk ID as read from module’s configuration. Note, that it’s set to the default value in the initial log record from module’s constructor, and then set to an empty string, when module loaded its configuration. And finally, as it was predicted, SCOM Agent created just one instance for both the rule and the monitor despite the target class has multiple instances served by local Agent.

[dd75c7aa-c3be-4933-898c-a35894fa3b51]:[none]:[14:43:37]: DiskProbeAction class instance is created. Host process PID: 6844; Managed thread: 27
[dd75c7aa-c3be-4933-898c-a35894fa3b51]:[]:[14:43:37]: Configuration is loaded.
[dd75c7aa-c3be-4933-898c-a35894fa3b51]:[]:[14:43:40]: Entering Start; Managed thread: 9.
[dd75c7aa-c3be-4933-898c-a35894fa3b51]:[]:[14:43:40]: First data item requested.
[dd75c7aa-c3be-4933-898c-a35894fa3b51]:[]:[14:44:24]: Entering OnNewDataItems; Managed thread: 6
[dd75c7aa-c3be-4933-898c-a35894fa3b51]:[]:[14:44:24]: Received 1 inbound data items of System.TriggerData type.
[dd75c7aa-c3be-4933-898c-a35894fa3b51]:[]:[14:44:24]: No shutdown in progress.
[dd75c7aa-c3be-4933-898c-a35894fa3b51]:[]:[14:44:24]: Competed output data item.
[dd75c7aa-c3be-4933-898c-a35894fa3b51]:[]:[14:44:24]: Next data item requested.

Now, let’s complete the second part of the experiment: make a copy of the disk probe based rule and monitor, but now add disk ID as a parameter. The key difference from the previous experiments, is that SCOM Agent substitute parameter’s value. In contrast to an operator editing an override. So now, rule/monitor configuration XML looks like:

<Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">  <DiskID>$Target/Property[Type="Windows!Microsoft.Windows.LogicalDevice"]/DeviceID$</DiskID>
</Configuration>

As expected, the log below shows four different instances of the module created. First instance is from the first part — the unnamed one. And then, we can see three instances, each created for the corresponding disk Id: C:, K:, and L:.

[74499182-7fc6-4f5d-b9b9-d17f79294839]:[none]:[15:03:35]: DiskProbeAction class instance is created. Host process PID: 6844; Managed thread: 39
[74499182-7fc6-4f5d-b9b9-d17f79294839]:[]:[15:03:35]: Configuration is loaded.
[f0ee56e8-e53d-47e5-9857-dec57ad65b81]:[none]:[15:03:35]: DiskProbeAction class instance is created. Host process PID: 6844; Managed thread: 39
[f0ee56e8-e53d-47e5-9857-dec57ad65b81]:[L:]:[15:03:35]: Configuration is loaded.
[ee2998cb-6f08-43d1-a98e-6172c631f9c2]:[none]:[15:03:36]: DiskProbeAction class instance is created. Host process PID: 6844; Managed thread: 39
[ee2998cb-6f08-43d1-a98e-6172c631f9c2]:[C:]:[15:03:36]: Configuration is loaded.
[f03e938b-2da2-4082-88bc-5d97b9537276]:[none]:[15:03:37]: DiskProbeAction class instance is created. Host process PID: 6844; Managed thread: 29
[f03e938b-2da2-4082-88bc-5d97b9537276]:[K:]:[15:03:37]: Configuration is loaded.
[f03e938b-2da2-4082-88bc-5d97b9537276]:[K:]:[15:03:37]: Entering Start; Managed thread: 36.
[f03e938b-2da2-4082-88bc-5d97b9537276]:[K:]:[15:03:37]: First data item requested.
[ee2998cb-6f08-43d1-a98e-6172c631f9c2]:[C:]:[15:03:37]: Entering Start; Managed thread: 17.
[ee2998cb-6f08-43d1-a98e-6172c631f9c2]:[C:]:[15:03:37]: First data item requested.
[74499182-7fc6-4f5d-b9b9-d17f79294839]:[]:[15:03:37]: Entering Start; Managed thread: 40.
[74499182-7fc6-4f5d-b9b9-d17f79294839]:[]:[15:03:37]: First data item requested.
[f0ee56e8-e53d-47e5-9857-dec57ad65b81]:[L:]:[15:03:37]: First data item requested.
[f03e938b-2da2-4082-88bc-5d97b9537276]:[K:]:[15:04:24]: Entering OnNewDataItems; Managed thread: 40
[ee2998cb-6f08-43d1-a98e-6172c631f9c2]:[C:]:[15:04:24]: Entering OnNewDataItems; Managed thread: 7
[ee2998cb-6f08-43d1-a98e-6172c631f9c2]:[C:]:[15:04:24]: Received 1 inbound data items of System.TriggerData type.
[74499182-7fc6-4f5d-b9b9-d17f79294839]:[]:[15:04:24]: Entering OnNewDataItems; Managed thread: 37
[74499182-7fc6-4f5d-b9b9-d17f79294839]:[]:[15:04:24]: Received 1 inbound data items of System.TriggerData type.
[f0ee56e8-e53d-47e5-9857-dec57ad65b81]:[L:]:[15:04:24]: Entering OnNewDataItems; Managed thread: 31
[f0ee56e8-e53d-47e5-9857-dec57ad65b81]:[L:]:[15:04:24]: Received 1 inbound data items of System.TriggerData type.
[74499182-7fc6-4f5d-b9b9-d17f79294839]:[]:[15:04:24]: No shutdown in progress.
[f03e938b-2da2-4082-88bc-5d97b9537276]:[K:]:[15:04:24]: Received 1 inbound data items of System.TriggerData type.
[f0ee56e8-e53d-47e5-9857-dec57ad65b81]:[L:]:[15:04:24]: No shutdown in progress.
[74499182-7fc6-4f5d-b9b9-d17f79294839]:[]:[15:04:24]: Competed output data item.
[f0ee56e8-e53d-47e5-9857-dec57ad65b81]:[L:]:[15:04:24]: Competed output data item.

Conclusions.

After this article, we’ve learned how to create very basic Probe Action managed modules for SCOM. And using managed modules is the most efficient way to create custom monitoring workflows for SCOM platform. Now, let’s summaries facts discovered in this research.

1. Managed modules are persistent. SCOM Agent creates an instance (object) of a C# class once, so then this instance is persistent until either SCOM Agent shuts down, or class’ assembly is being upgraded (assembly must use strong names signature to support this).
2. When SCOM Agent shuts down, no managed modules receive any notifications.
3. When module’s class library is upgraded, SCOM Agent sent a graceful shutdown notification to a current instance.
4. When managed module is a part of a composite data source, OR is a data source, SCOM Agent creates the same number of module instances, as the number of unique configurations for this data source.

That all together helps to reduce monitoring footprint a lot. For example, persistence of modules allows to make connection to an API, a cloud, a DB server, etc. only once, and keep this connection alive (and only reconnect when expires/broken).

Coockdown (which is #4) helps saving host memory, but more important, this allows to do batch probes. Say, we have disk usage monitor based on managed module. We can either supply disk Id as a parameter, which will create a module instance for each disk, OR, have a single module, which returns multiple output data items — one data item for each disk. With a condition detection module, these items can be filtered down to particular disk instance (I’m going to cover this in another planned article “Creating high performance and large scalable SCOM Management Packs”).

The End.