Services overview


The MainView Middleware Monitor services do not receive data directly from the Agent. Rather, they register with the MVMM  Topic Service as subscribers for the data that they are interested in. The Agent then sends one copy of each piece of information to the MVMM  Topic Service, which then forwards a copy to each registered subscriber. This process minimizes the amount of data that needs to be sent and the corresponding overhead. It also makes it much easier to support new technologies since the bulk of the components are unaffected (a new Extension is simply added).

During installation, the following services are installed on the services server:

A set of traffic lights in the lower right corner of the Monitor Console,indicates the status of the following services and the database connection.
 The lights represent:

  • A: MVMM  Application Service
  • E: MVMM  Event Service
  • H: MVMM  History Service
  • T: MVMM  Topic Service

The colors represent:

  • Green: The service is running and, where applicable, connected to the database.
  • Yellow: The service is running but not connected to the database. The database might not be running or there might be power or network problems.
  • Red: The service is not running.

MVMM  Topic Service


The MVMM  Topic Service gathers information as topics collected by the Agent and distributes that information to other services. The MVMM  Topic Service also manages the topics and makes them available to the clients.

The MVMM  Topic Service is responsible for routing data associated with topics to subscribers in real time. The Agents report updated topic data to the MVMM  Topic Service, which then passes it along to the Monitor Console or to other services, like the MVMM  Event Service. The Topic Service also monitors the agent connection and reports topics based on the status. These topics can be used to trigger actions in the vent Service (such as sending an e-mail message if an agent becomes unresponsive).

MVMM  History Service


The MVMM  History Service stores and manages a record of topic values according to user specifications. The History Service also makes the data available to clients so that they can analyze and report the historical topic values.

The MVMM  History Service stores and maintains topic data for analysis. The Monitor Console uses this information to populate trend charts, views, reports, and graphs. Collecting all information for all possible topics would create a massive database very quickly, so you control what information is collected and how it is stored. MVMM  enables you to control high-resolution (short-term-data less than 40 days old) data differently and separately than low-resolution data (long-term-data stored based on database size allocation).

All monitored information is passed from the monitoring extension to the agent. From there it goes to the MVMM  Topic Service and on to the History Service. The MVMM  History Service passes the data to the database where it is stored. High-resolution data is stored for up to 40 days before it is compressed into low-resolution history.

 

For information about collecting history data and using trend charts, reports, charts, and views, see the relevant sections in Using.

 

historyDataFlow.png

MVMM  Application Service


The MVMM  Application Service acts as a proxy for users logged in to the Monitor Console. When an authenticated user opens a view, the Application Service subscribes to all topics needed to populate that view and forwards those to the individual user’s console. The Application Service performs the following functions:

  • Stores and serves media files (images, views, reports) to the Monitor Console
  • Supports web browser access to the Monitor Console.
  • Performs security validation and provides user and group management, rights management, and authentication within MVMM .

The executable file is called Wrapper.exe (Windows) or wrapper (Linux).


Note

The wrapper.ping.timeout parameter in qpas.conf allows you to set the timeout period for a long action.

To avoid timeouts/JVM restarts set:

wrapper.ping.timeout=t

where t is in seconds.

MVMM  Event Service


The MVMM  Event Service constantly monitors and compares topic values against the trigger conditions of any event rules that have been created. If the incoming data matches one of the event trigger conditions, the defined action is taken. You are not limited by the number of topics for your event rules or by the number or actions that you can take based on an event.

The Event Service can perform the following actions:

  • Send a Monitor Console alert
  • Execute an external program
  • Send an e-mail message
  • Log a message to a file
  • Log an SQL message to a file
  • Write to the event journal
  • Send a message to a IBM MQ queue
  • Send an SQL message to a IBM MQ queue
  • Send a message to BMC Event Manager (BEM)
  • Use time to delay a message.

You can define rules that start actions when certain conditions are met. You have full control over defining the conditions, including time-based events and topic-based events.

In the event of a shutdown (hard or soft), the MVMM  Event Service recovers the state of any outstanding events at the time of the shutdown. This prevents events from firing multiple times due to shutdown.

All monitored information is passed from the monitoring extension to the agent. From there it goes to the MVMM  Topic Service and on to the MVMM  Event Service. The MVMM  Event Service determines if any events have occurred based on the rules and templates. If so, the MVMM  Event Service takes action, which could involve the MVMM  Client Gateway Service or the database (depending on the type of action).


MVMM  Client Gateway Service


The MVMM  Client Gateway Service is used in conjunction with the Event Service for automating events.

The Client Gateway Service is automatically installed along with the Application Service or Event Service. If the Application Service and Event Service are installed on separate machines, each has its own Client Gateway Service.

MVMM  ProactiveNet Service


The MVMM  ProactiveNet Service publishes MVMM  monitored data to TrueSight Infrastructure Management or ProactiveNet that wouldn't otherwise be available to the products. As updates arrive at the MVMM  service tier, they are published to the MTM Knowledge Module (KM) running in a Patrol Agent. From that point on, TrueSight Infrastructure Management or ProactiveNet gathers the data from the Patrol Agent.

 

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