User goals and features

MVMM enables you to collect history data using the History tab of the Monitor Console. The history database stores this history data as raw (high-resolution) and summarized (low-resolution) values of attributes, where they are available for querying and generating reports (you can also generate standard daily, weekly, or monthly reports for the properties of a selected object).

Once history data is collected, you can use it to understand trends via a trend chart in a real-time view. The trend chart graphs the value of one or more properties over time; there are a number of trend charts in the out-of-the-box physical views, particularly for key performance metrics. In logical views, it is useful to have trend charts comparing the values of a key attribute from multiple artifacts like the chart shown in the example view below that compares the average elapsed time between the various steps in a transaction pathway. This allows you to quickly see which step is the performance bottleneck (shown below in the yellow line, Back End).

When a chart in a logical view is opened, the MVMM Application Service subscribes to the current value of the topics on the chart and begins updating the chart in real time with new publications as long as the view remains open. In addition, the Console also makes a direct query to the history database to return past values of the topics. If there is no history, of course, no values will be populated, while any new values will populate.  

Dashboards help avoid the time needed to log in to multiple systems to look at different log files, screens, etc, in turn reducing the time to problem resolution. With all the relevant objects and properties collected in one view (a dashboard), the typical application user has everything required for their job role (including application performance analysis, health assessment, and recovery) on one screen across multiple platforms (whether distributed or mainframe).

A dashboard can show attribute data for many different types and type instances simultaneously; the dashboards required depend on the MVMM implementation and user needs for data visibility. For example, you can create a dashboard:

• that shows the status of some WebSphere MQ queue managers, WebSphere MQ Integrator brokers, and DB2 databases.
• to monitor type instances of interest to a specific group of users.
• to monitor type instances in a specific geographical location.

In general, dashboards can be customized to contain:

• business data used by business analysts and monitoring operators.
• infrastructure data used by system administrators and other support personnel.

Use the Dashboard Wizard to intuitively create and modify dashboard templates, which are used to create dashboard instances.

With the need for automation ever-prevalent, MVMM enables you to apply a number of out-of-the-box monitoring policies to your environment, whether it be a production system or development and testing systems. These policies allow the dynamic configuration of objects based on sets of expressions and actions that are configured in a policy. And because every environment is unique, you can easily copy and tweak the supplied MVMM policies; you can also create your own policies.

Policies are defined in the Policy tab of the Monitor Console, and are comprised of the following key elements:

• Agent policies and groups - Rules, and groups of rules, to match agents
• Object policies and groups - Rules, and groups of rules, to match monitoring objects (e.g. queue managers)
• Expressions - Regular expression-like pattern matches, used to match policies or groups
• Policy actions - Actions to take when a policy matches

These elements can be combined together to form an automated monitoring policy, which can include, for example:

"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"

For further information, see Defining policies.