Policies supplied with MainView Middleware Monitor
MainView Middleware Monitor (MVMM) provides a large set of sample policies. These out-of-the-box policies contain general monitoring recommendations and are ideal for getting up and running with policies. If these policies do not meet your requirements, you can create your own. Note that because every environment is unique, you can easily copy and modify the supplied policies.
The self-monitoring and IBM MQ monitoring policies are supplied out of the box. The policies for other technologies such as Apache ActiveMQ, IBM DataPower, IBM Integration Bus, IBM HTTP Server, BMC AMI Ops Monitor for MQ, TIBCO EMS, and IBM WebSphere Liberty are supplied within mqsimport files within a zip file for each technology in the Samples/EventPacks directory of the BMM Install media.
When running the upgrade installer, these policies and their child objects will be overwritten.
The policies themselves are read-only so MVMM prevents the overwriting of policies that are actually in use. However, these policies refer to history templates and event templates which, in turn, refer to event triggers and event actions. Those child objects, although supplied with MVMM, are NOT read-only and it is possible that the policy definitions in use in your environment may reference those child objects directly.
As stated in the Upgrading section, MVMM replaces these files during an upgrade. This has the advantage that these event and history templates will remain current. However, if you have changed the event templates, event actions, event triggers, or history templates and left them with the supplied names, these will be overwritten by the upgrade process.
To avoid the possible loss of work, it is recommended you back up any such modified versions of the supplied templates using the mqsexport command. After the upgrade, you can restore your modified versions using the mqsimport command. It is recommended you copy any such modified objects and adjust your policies to reference your copies to avoid this possibility in future upgrades.
The Agent Description field in the agent properties can be used to automatically associate a set of policies with the agent machine upon discovery. If you use the Bootstrap package distribution from the Launch page, there is a field on the Agent Distribution page where various information can be added to the agent description attribute to use for searching. This enables you to add particular key information (like technology on a specific machine, or geographic/logical grouping information) that can be used to identify this machine as matching the initial Agent policy expression. The agent description information you add is visible in the agent's Description attribute on the Object Repository tab of the MVMM Monitor Console. See, Setting-the-agent-description.
For each technology, the supplied policies come with a number of Agent Policies that implement various monitoring levels. Some technology may not have all monitoring levels.
- Minimal - This level ensures there is almost no automatic monitoring, although will automatically keep history on the BMM Agent and the top level component of the technology (for example, the MQ Queue Manager, IIB Broker, or EMS Server), and will provide Console alerts if the monitoring extension has lost contact with the underlying technology. Choose this level if you wish to control your monitoring mostly manually (as in previous versions of MainView Middleware Monitor ( MVMM ) rather than automatically, but need to ensure the absolute core is monitored.
- Basic - This level does everything the Minimal level monitors, but also discovers and selects for monitoring the underlying objects (such as MQ queues and channels, Broker Message Flows, WAS EJBs, and DataPower Multi-Protocol Gateways). In addition, it stores history on the key metrics of those objects. Note that this level does not alert automatically, other than the minimal Console alerts on the BMM self-monitoring. Choose this level if you want to ensure that objects are discovered and populated in the Operations tab of the Management Console automatically but wish to manage your events manually.
- Standard_NNN - This level is intended to implement MainView Middleware Monitor best practices for monitoring. The monitored objects are discovered and populated in the Management Console Operations tab. Historical data is collected on all key metrics, and alerts are set up automatically to notify you of key conditions for all monitored objects. As this level includes alerting, there are several variants specified by the NNN to control where the event notifications go.
If you are using TrueSight Operations Management (or the older BMC ProactiveNet Performance Management or BMC Event Manager), then you should choose the _BEM variant. The _EMail variant will send event notifications via email. The _LogToFile variant will write the event notifications to a specified log file.
Note that all of these eventing options will require some general configuration.- For the BEM variant, you must configure BMC Event and Impact Integration.
- For the _EMail variant, you must configure the target email server and recipient in the EMail_Generic Event Action (In Edit mode in the Management Console, select the Events tab, then select the Actions sub tab. From the list of Actions, select the EMail_Generic action pipeline, right-click on the email action and select Properties. Enter the SMTP Host, SMTP Port, Sender, To, CC, and BCC information. Click OK and then click the Commit button). For further details, see Defining events, triggers, and actions.
- For the _LogToFile variant, you must specify the target log file by editing the LogToFile_Generic Event Action (In Edit mode in the Management Console, select the Events tab, then select the Actions sub tab. From the list of Actions, select the LogToFile_Generic action pipeline, right-click on the File Message action and select Properties. Enter the intended path and file name for the log file. Click OK and then click the Commit button). For further details, see Defining events, triggers, and actions.
- ALL_NNN - This level monitors and stores historical data on all objects and alerts on essentially every condition that MainView Middleware Monitor believes could be of interest. As with the Standard_NNN level, there are _BEM, _EMail, and _LogToFile variants. Choose this policy in an environment where you wish to explore the possible monitoring capabilities. It is generally not recommended that you select this policy level in a production environment because it may generate a large number of alerts.