Policy architecture

Agent Policies

Agent Policies provide a reference to exactly one Expression and one or more Object Policies (or Object Policy Groups, as described below). The Expression (aside from its Name and Description) provides a Boolean condition based on the attributes of the agent. If that condition evaluates to True, then the Agent Policy matches and its referenced Object Policies are applied to monitored objects discovered by that agent's extensions. 

For example, the supplied Agent Policy called WMQ_Agents_Standard_BEM references an Expression called Agents_TECH_WMQ, which is designed to match all agents that have the MQ monitoring extension installed. 

It is important to note that the Expression for an Agent Policy only has access to the properties of the agent itself (and not properties of child objects like the extensions). This means that the Agent Policy cannot directly know if the MQ monitoring extension (or any other) is installed. To work around this, the supplied Agent Policies make use of the agent's Description property and assume that you have set helpful values there.

The Description format expected by the policies is ENV=EnvironmentType;TECH=Tech1,Tech2,...  where EnvironmentType is a designator like PROD, TEST, or DEV and Tech1 and Tech2 (and ...) are technology abbreviations like WMQ, WMB, DataPower, EMS, or WAS that indicate which extensions are on the agent.  

Next, we need to know what to actually do for those agents that matched.

Policy Actions

First, we use Policy Actions. To access the Policy actions, click the Back button above the Expression to return to the Agent Policy properties and then select the Policy Actions tab. A list of actions to take directly against each matching agent is displayed, as shown below.

In this example, the WMQ_Agents_Standard_BEM Agent Policy references 4 Policy Actions; 3 of those Policy Actions associate Event Templates with each of the matching agents. Note the naming convention - BMM_Agent_AddEventTemplate_agentUnavailable_BEM adds an event template to the objects of type agent in the BMM monitored technology (self-monitoring in this case). The condition that drives this event will be that the agent is unavailable and the action will be to send an event to the BMC Event Manager in TrueSight Operations Management. Thus, this Agent Policy will send alerts to TrueSight Operations Management when the agent is unavailable, when it is frequently disconnecting and reconnecting and when it has a slow network connection to the BMM Server. This also results in BMM collecting history on the key properties of the agent as defined in the History Template called SAMPLE.

Note that these Policy Actions refer to objects outside of the policies themselves. You can see the corresponding Event and History Template details by accessing the History and Event tabs respectively. 

Policy Actions are applied directly against the matching agents. However, the real purpose of the agent is to monitor underlying objects, so policies also need to control what is done to the child objects. This is where Object Policies come in.

Object Policies

If you click the Object Policies tab, you can see the list of Object Policies that will be applied to things monitored by this agent's extensions, as shown below. 

This Agent Policy references one Object Policy called BMM_Extension_Standard_BEM, which, as its name implies, will apply to child objects of type extension in the BMM technology group and the Policy Actions that it takes will provide a standard level of monitoring and that event notifications from those actions will go to TrueSight Operations (note that there are EMail and LogToFile equivalents also supplied for those who use different event managers). If you select that Object Policy and click the "Go To" button, you can see the details of that Object Policy, as shown below. 

As with Agent Policies, Object Policies reference exactly one Expression. The Expressions are exactly like those for Agent Policies except that their Boolean condition can reference the properties of the Type from the Object Policy rather than the Agent properties. Beyond that, everything is very similar.

You can see that this expression is designed to match all extensions that are children of this agent except the QPCFG extension (unlike the other extensions, this MQ configuration extension does not do monitoring). In addition, you can see that an Object Policy can reference one or more Policy Actions. Note that this is subtly different than Agent Policies which can reference zero or more Policy Actions. It would not make any sense to have an Object Policy at all if you want to do nothing, where with Agent Policies you might not want to do anything with the agent itself, but with its children. To see the Policy Actions referenced by this Object Policy, click the Policy Actions tab, as shown below.

You can see that this Object Policy performs only one action (BMM_Extension_AddEventTemplate_LowConnections_BEM) on the matching extension objects. As its name implies, this will associate an event template with all of the matching extensions (again all but QPCFG from the expression). That event template will send an event to TrueSight Operations Management when the number of active connections from the extension is low, meaning that it cannot connect to the underlying monitored technology (like an MQ Queue Manager or IIB Broker). 

Agent Policy Groups and Object Policy Groups

One key concept of the policy architecture remains: Groups. 

There are two types of Groups - Agent Policy Groups and Object Policy Groups. 

Object Policy Groups

When you are building an Agent Policy you can individually reference each Object Policy that you want to apply, as mentioned above. Note however, that Object Policies are reusable across multiple Agent Policies. In real policies, you often find that several Object Policies go together and adding them individually to multiple Agent Policies becomes tedious and prone to error.  

For this reason, you can join multiple Object Policies into an Object Policy Group and then directly reference that Group from the Agent Policy (or from another Object Policy Group to form nested groups). Note that all Object Policies in an Object Policy Group must reference the same Type.

Once you have grouped Object Policies together, you then simply reference the Object Policy Group from the Agent Policy just like an individual Object Policy. To see this, you can return to the WMQ_Agents_Standard_BEM Agent Policy by clicking the Back button from the previous screen and then select the Object Policy Group tab, as shown below.

You can see that the WMQ_Agents_Standard_BEM Agent Policy references one Object Policy Group called WMQ_POLICY_Standard_BEM. Selecting this Object Policy Group and clicking the "Go To" button will display the detailed properties, as shown below.

In the example above, you can see that the WMQ_POLICY_Standard_BEM Object Policy Group includes two Object Policies called WMQ_LocalQ_TransmissionQ and WMQ_QMgr_ALL_BEM. As its name implies, these Object Policies will apply to MQ Local Queues that are transmission queues and to all MQ Queue Managers respectively.  If you wish to understand further the details of this or any other BMC supplied policy, see Policies-supplied-with-MainView-Middleware-Monitor.

Note that the Object Policies included in the Object Policy Group will be evaluated under the Agent Policy just as if they were directly referenced.

Finally, note that the Object Policy Group properties also contains an Object Policy Group tab that allows you to nest Object Policy Groups inside other Object Policy Groups. 

Agent Policy Groups

For import/export and promotion purposes as well as operational enablement/disablement of policies, you might want to work with multiple Agent Policies at one time. For this reason, MainView Middleware Monitor allows you to join the Agent Policies into Agent Policy Groups.

From a runtime perspective, each Agent Policy in an Agent Policy Group is evaluated and handled separately with one exception. It is possible to directly reference Policy Actions from Agent Policy Groups so that common actions are taken against all member agents. Otherwise, Agent Policy Groups serve administrative and operational purposes.

In summary

To summarize this section, the Policy Architecture diagram we started with at the start of the section looks like the following once Groups are added.