Policies and Event Packs overview
Why aren't policies and event templates for all technologies visible out of the box?
For legacy reasons, the MQ monitoring components are visible out of the box. For example, the MVMM Agent Bootstrap package that is the basis for all MVMM Agents contains not only the Agent (qpea) and the Configuration Agent (bmmtm_agent) and their utilities, but automatically contains the MQ Monitoring Extension (qpmon) even if you intend to monitor only DataPower or other technologies.
Monitoring extensions for other technologies (such as activemq_mon, bmmpa_datapower, qpwmb, qpwasmon, liberty_mon, and qptibems) are then added to the Agent through the Package Distributions tab. Similarly, the supplied event templates (and the underlying triggers) and the supplied policies are not included in the Management Console by default. To add them, you must import the Policy and Event Pack for each technology.
What Policy and Event Packs are supplied?
Policy and Event Packs are currently supplied to cover the following technologies (with their technology prefix included):
- Apache ActiveMQ (ActiveMQ)
- IBM DataPower (DataPower)
- TIBCO EMS (EMS)
- IBM HTTP Server (IHS)
- BMC AMI Ops Monitor for MQ (MVMQ)
- IBM WebSphere Application Server (WAS)
- Oracle WebLogic Server (WLS)
- IBM Integration Broker / IBM App Connect Enterprise (IIB/ACE).
- IBM WebSphere Liberty (Liberty)
These Policy and Event Packs can be found in sub-directories of the Samples/EventPacks sub-directory of the MVMM Server installation.
What is contained in each Policy and Event Pack?
The foundation of each Policy and Event Pack is a library of policies with policy actions to register objects for monitoring, associate objects to history templates and associate objects to event templates.
A key component of of the event templates are the related event triggers. An event trigger is a Boolean condition that indicates a problem or other condition that might require alerting an administrator or taking other action. For example, the DataPower OpState property might be 0 indicating that a service is not running at the same time that the AdminState for that service is 1, indicating that it has not been intentionally stopped. In this case, the event trigger would be OpState !=0 && AdminState==1.
Some event triggers are obvious and indicate direct problems like a Integration Node being down. In such a case, you can attempt to restart the Integration Node, or more likely notify an administrator (perhaps via email) to restart the Integration Node.
Generating emails or executing programs are examples of event actions. Some other event triggers, however, are only informational. That is they may be one symptom of a larger problem requiring attention. If you do not capture enough of these conditions, then critical troubleshooting information may not be available to the administrator without searching through the console. However, if you capture all possible conditions, then the noise may overwhelm the administrator. Correlating such event streams is the function of event managers like the BMC Event Manager (BEM) included in the TrueSight Infrastructure Management (TSIM) platform. Thus, a very common event action is to send the information to BEM or another event manager.
Finding the Policy and Event Packs
First, identify the technologies that are relevant to your environment.
Then find the technology prefix for your technology (see the What Policy and Event Packs are supplied section above). Log in to the MVMM Server system and navigate to the MVMM installation directory. Change directories to the Samples/EventPacks sub-directory (cd Samples/EventPacks on Linux).
Where to go from here
Once you have identified and found the Policy and Event Pack refer to the appropriate details in the Policies-supplied-with-MainView-Middleware-Monitor, which includes instructions for importing and a more in depth description of the content.