Defining policies

MainView Middleware Monitor (MVMM) provides a set of out-of-the-box policies that contain general monitoring recommendations. If you simply want to get up and running quickly, use these policies "as is", or see Getting-started-with-policies and Policies and Event Packs overview for further information. 

Because every environment is unique, you may want to copy and adjust the supplied policies; if so, see Policy-architecture, which describes how policies are designed. You can also create your own policies. For more advanced information about the structure of the existing policies, see Policies-supplied-with-MainView-Middleware-Monitor.

Related topics

Overview-of-policies

Overview-of-objects

Getting-started-with-policies

Policies-supplied-with-MainView-Middleware-Monitor

A quick overview


Policies apply to objects. Refer to an Overview of objects if you don’t have an understanding of objects. Policies are defined via the Policies tab, which allows the dynamic configuration of objects based on sets of expressions and actions.   Policies are activated when an object is added, removed or changed.


  • Policy Actions – An action to perform (For example, associate a newly added object to an event template).
  • Expressions – Criteria to determine whether an object matches (For example, the description contains the word “QA” and the name contains the word “Test”).
  • Object Policy – Specifies the list of actions to be taken for an object if the object satisfies the policy’s expression. Most actions perform one operation when an object is added and another when removed (For example, associate the added object to a history template or remove the association for a removed object).
  • Object Policy Group – A collection of object related policies or other object policy groups.
  • Agent Policy – Specifies the list of object policies or object policy groups that apply to objects belonging to agents that satisfy the agent policies expression (For example, the agent’s description contains TECH=MQ would likely have a set of MQ related object policies).
  • Agent Policy Groups – A collection of related agent policies or other agent policy groups.  What is considered related is entirely under your control for your environment. The ability to nest agent policy groups and agent policies within other agent policy groups can help with re-usability and organizing your policies.


What is considered related is entirely under your control for your environment.  Some examples might be, production, qa, MQ, DataPower. The ability to nest object/agent policy groups and object/agent policies within other object/agent policy groups can help with re-usability and organization of your policies.

These elements can be combined together to form a monitoring policy, which can include the following examples:

"Every Monday, at 2am, run discovery on agents with a "Production" role"
"Register all local queues named "QA.*" found on agents running with a "QA" role"
"Associate all queues named with a prefix of "Prod" to the Product event template"

Note

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.

The Policy Service

The Policy Service runs in the MVMM Application Service. It subscribes for updates from the Topic Service, matches those updates to a user-defined monitoring Policy Model, and takes the actions described in the Policy Model. It also evaluates scheduled policies.

Permissions required to view and edit policies

The following two permissions (set in the Security tab, see Defining-user-access-and-security-settings for details) are required to see the objects in the Policies tab or perform actions on them:

  • Access Policies Tab
  • Edit Policies

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*