BMM (self-monitoring) policies
This section provides full details of the supplied BMM policies for self-monitoring of the TrueSight Middleware and Transaction Monitor (TMTM) service set to enable you to customize it for your specific environment.
If you simply want to get started using the policy as quickly as possible (with no customization), see Getting started with policies. In order to gain a better understanding of policies, see Policy architecture.
In general, for supplied policies there are _Minimal, _Basic, _Standard_NNN, _ALL_NNN monitoring levels. However, not all levels are supported for each technology type.
It is important to note that, as the BMM policies are self-monitoring, the BMM objects are handled a bit differently than the other groupings. In BMM, there are three major groupings of objects: agents, extensions, and service components.
BMM 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 WMQ_Agents_Standard_BEM Agent Policy includes four Policy Actions. All four of those are BMM_Agent_... because they affect the monitoring of the agent.
Standard_NNN monitoring level
The example above uses WMQ_Agents_Standard_BEM, but this will be exactly the same for all technologies (WMB, 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 WMQ_Agents_Standard_EMail Agent Policy, you would see BMM_Agent_AddEventTemplate_agentUnavailable_EMail (rather than _BEM).
For the purposes of this section, we just want to understand the supplied BMM_ policies so we'll ignore the specific technology and the event action target and focus on the function.
Note that the Standard level policies have four actions: UseHistoryTemplate_SAMPLE, AddEventTemplate_agentUnavailable, AddEventTemplate_HighPingTime, and AddEventTemplate_HighReconnectRate.
The UseHistoryTemplate_SAMPLE causes the BMM 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.
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 BMM_Agent_UseHistoryTemplate_SAMPLE Policy Action.
Because they are so core to the solution, there is no Minimal level of monitoring for BMM agents. Even the Minimal level Agent Policies use the Basic level of BMM agent monitoring.
The ALL_EventTarget level Agent Policies use the same Policy Actions as the Standard_EventTarget Agent Policies but add one additional Action: BMM_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.
BMM_ extensions and policies
The second object type in BMM 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, however, 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.
BMM_Standard_NNN Object Policy
Note that the example below is the WMQ_Agents_Standard_BEM Agent Policy so it references the BMM_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 BMM_Extension_Standard_LogToFile Object Policy. The BMM_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 BMM_Extension_ALL level
There is no ALL level for BMM extensions. The ALL level Agent Policies reference the Standard Level BMM Extension Object Policy.
BMM_Extension_Basic Object Policy
The Basic and Minimal level Agent Policies all reference the BMM_Extension_Basic Policy. This is identical to the BMM_Extension_Standard_BEM policy shown above, other than that the event target is the TMTM Monitor Console rather than TrueSight Operations Management.
The BMM_Extension_Minimal level
Because extension monitoring is so fundamental, there is no Minimal level for BMM extensions. The Minimal level Agent Policies reference the BMM_Extension_Basic Object Policy.
BMM Service Set monitoring policies
The final component of BMM itself is the server.
Like MQ queue managers or DataPower devices, the BMM server is made up of multiple components so it has its own Agent Policy named BMM_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 itself down, it could not send an event indicating so. Thus, it is recommended that you monitor the BMM 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 BMM itself.
However, it is useful to keep historical performance metrics on the server so a Basic level Agent Policy is supplied.
This Agent Policy applies to the BMM 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 (BMM_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 hisotry 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.
BMM_ServiceSet_Standard, ALL, and Minimal levels
Since BMM service set monitoring is quite standard, no Minimal level Agent Policy is supplied.
Also, because the BMM 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.