MVMM (self-monitoring) policies

MVMM agents and policies

Performing actions on the agent must be part of every other Agent Policy. Thus, the Policy Actions for each level are used directly in each of the technology policy. For example, the IBM_MQ_Agents_Standard_BEM Agent Policy includes four Policy Actions. All four of those are MVMM_Agent_... because they affect the monitoring of the agent. 

Standard_NNN monitoring level 

The example above uses IBM_MQ_Agents_Standard_BEM, but this will be exactly the same for all technologies (IBM IIB/ACE DataPower, and so on). Also, the idea will be the same for the EMail and LogToFile variants. Only the target action will be different. For example, in the IBM_MQ_Agents_Standard_EMail Agent Policy, you would see MVMM_Agent_AddEventTemplate_agentUnavailable_EMail (rather than _BEM).

For the purposes of this section, we just want to understand the supplied MVMM_ policies so we'll ignore the specific technology and the event action target and focus on the function.

The UseHistoryTemplate_SAMPLE causes the MVMM History Service to store historical data on the key properties of the agent as defined by the rules in the SAMPLE History Template. If you need more information about history templates, see History rules and templates.

The other three Policy Actions add event rules to notify you when the agent is disconnected from the server, when the network link between the agent and the server exceeds a threshold (10 ms by default but customizable), and finally when the number of reconnections in the last sample interval is greater than a threshold (again, customizable just as with the PingTime threshold). This last condition is necessary to detect a condition where the agent happens to be connected at the exact time of the sample publish but is experiencing frequent network interruptions between samples.

There are several common tasks that you may need to perform when customizing policies such as changing thresholds or adding new events. These are described in Common-tasks-when-customizing-policies.

Basic Level

In keeping with the Basic level of monitoring, the Technology_Agents_Basic policies do not do any eventing. Thus, the Policy Actions for those contain only the MVMM_Agent_UseHistoryTemplate_SAMPLE Policy Action.

Minimal Level

Because they are so core to the solution, there is no Minimal level of monitoring for MVMM agents. Even the Minimal level Agent Policies use the Basic level of MVMM agent monitoring.

ALL_NNN Level

The ALL_EventTarget level Agent Policies use the same Policy Actions as the Standard_EventTarget Agent Policies but add one additional Action: MVMM_Agent_AddEventTemplate_HighTimeSkew_EventTarget. This adds a notification when the time clock of an agent system is very different from that of the server. Such conditions can lead to timestamps in properties being different than expected. Most of the time this is not an issue, but note that this is included only in the ALL level.

MVMM_ extensions and policies

The second object type in MVMM is the extension.

Like the agent, the extension is really part of the underlying monitoring so its Policy Actions are included under the Agent Policy for the individual technology. Unlike the agents, the extensions are children of the agent so the Policy Actions are not directly on the Agent Policy but encapsulated in an Object Policy under each technology specific Agent Policy, as shown below. 

MVMM_Standard_NNN Object Policy

The following example is the IBM_MQ_Agents_Standard_BEM Agent Policy so it references the MVMM_Extension_Standard_BEM Object Policy. This same Object Policy will be referenced by all technologies. There are _EMail and _LogToFile variants that are referenced for all technologies by the corresponding Agent Policy variant. 

For example, the DataPower_Agents_Standard_LogToFile Agent Policy references the MVMM_Extension_Standard_LogToFile Object Policy. The MVMM_Extension_Standard_NNN Object Policy is more straightforward (see below). It contains only one Policy Action that adds an event notification when the Extension Connection Count is low. That means that the extension is disconnected from the agent. The only other point of note is that the expression for this Object Policy matches all extensions except the MQ configuration extension. That extension is quite different from the MQ monitoring extension and other monitoring extensions. Since it only connects when a user is actually configuring MQ so it is not an issue when the MQ configuration extension is not connected to the agent.

The MVMM_Extension_ALL level

There is no ALL level for MVMM extensions. The ALL level Agent Policies reference the Standard Level MVMM Extension Object Policy.

MVMM_Extension_Basic Object Policy

The Basic and Minimal level Agent Policies all reference the MVMM_Extension_Basic Policy. This is identical to the MVMM_Extension_Standard_BEM policy shown above, other than that the event target is the MVMMMonitor Console rather than TrueSight Operations Management.

The MVMM_Extension_Minimal level

Because extension monitoring is so fundamental, there is no Minimal level for MVMM extensions. The Minimal level Agent Policies reference the MVMM_Extension_Basic Object Policy.

MVMM Service Set monitoring policies

The final component of MVMM is the server.

Like MQ queue managers or DataPower devices, the MVMM server is made up of multiple components so it has its own Agent Policy named MVMM_ServiceSet_Basic.

Because there are very serious limitations to self-monitoring of any form, it is unreliable to do eventing on problems with the server. For example, if the Event service is down, it could not send an event indicating so. Thus, it is recommended that you monitor the MVMM Service components and logs using standard process and log monitoring technologies (TrueSight Infrastructure Management to monitor the processes and TrueSight Data Analytics to monitor the logs) independent of MVMM.

However, it is useful to keep historical performance metrics on the server so a Basic level Agent Policy is supplied.

MVMM_ServiceSet_Basic

This Agent Policy applies to the MVMM server itself and turns on historical data collection for all server components using the SAMPLE history templates. 

This Agent Policy contains one Policy Action to turn on monitoring at the top level. It then references one Object Policy Group (MVMM_ServiceSet_Basic) that joins the individual Object Policies for each of the underlying components (see below). 

Each of those underlying Object Policies simply has one Policy Action to turn on history using the SAMPLE history template. Examining the list you can see that these Object Policies cover the statistics from the logs, the Windows/UNIX process stats, the Message Block Pools (for communications), the Service Pool itself, and the statistics on policy evaluation and execution.

MVMM_ServiceSet_Standard, ALL, and Minimal levels

Since MVMM service set monitoring is quite standard, no Minimal level Agent Policy is supplied. 

Also, because the MVMM server cannot reliably alert on its own problems, no Standard or ALL levels are supplied (since those would normally add the event logic). Therefore you should use the Basic level.

Where to go from here

Now that you have imported the Policy and Event Pack for this technology, go to Getting-started-with-policies to enable them.