Working with the subscriber services

The installation program installs the following TrueSight Middleware and Transaction Monitor services, which run as services on Windows systems and daemons on Linux systems. Depending on your needs (host operating system and required features, such as automation, SNMP, or secure web server), additional configuration might be required following installation. 

If the services and the database run on the same system, the database should be set to start before the services. Set a services start dependency for each service to start after the database is running.

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: TMTM Application Service
  • E: TMTM Event Service
  • H: TMTM History Service
  • T: TMTM 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.

TMTM Topic Service

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

The TMTM Topic Service is responsible for routing data associated with topics to subscribers in real time. The Agents report updated topic data to the TMTM Topic Service, which then passes it along to the Monitor Console or to other services, like the TMTM 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).

TMTM History Service

The TMTM 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 TMTM 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. TMTM 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 TMTM Topic Service and on to the History Service. The TMTM 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.

The Event and Application services function in real time. There are limits to what you can do with real-time data, however. Often, you want to look back at what the value of a given property was at some time in the past. To enable this, TrueSight Middleware and Transaction Monitor must store the past values of Attributes in the database where they may be queried later. It is the History Service that does this. Like the other Subscriber Services, the History Service subscribes to particular topics of data being published by the Agent Extensions through the Topic Service.

It is not useful to keep history on all attributes.

The Name of a Local Queue does not change so there is no need to keep history on it. Even many numeric attributes such as the Trigger Type are generally static and there is no reason to track their values over time. If you are looking for an audit log of manual changes to such properties, you should be using TrueSight Middleware Administrator rather than TrueSight Middleware and Transaction Monitor.

On the other hand some properties, such as the CurrentQDepth and MsgDeqRate, change frequently with no manual intervention and it is important to keep history on such values.

Thus, TrueSight Middleware and Transaction Monitor provides a History Template for each Physical Type that provides a list of the Attributes associated with that type. In this template, you can check the boxes next to the attributes for which you want history. As with Event Templates, History Templates are defined for each Physical Type.

Note

History applies only to Physical Types since Logical Types are collections of physical artifacts and history on the logical would be redundant.

You then associate each instance with one or more templates for that type. The History Service then subscribes to all topics checked in the associated templates. 

TMTM Application Service

The TMTM 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 TMTM.

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

The TMTM Application Service and Views

The key to understanding the Application Service deliverables is to understand the concept of Views.

In TrueSight Middleware and Transaction Monitor, the individual data fields monitored by the Agent Extensions are called Attributes. Each Attribute is assigned to a specific class of object called a Physical Type. 

Example

ComMQSoftwareWebSphereMQLocalQueue is a Physical Type that owns Attributes for all queue properties such as CurrentQDepth, MsgDeqRate, InitQName, Description, …

This relationship between Attribute and its parent Physical Type is defined in the TrueSight Middleware and Transaction Monitor Database and stored locally in the Agent’s eaa.xml file. When a data point is published, the actual Topic is PhysicalType!Attribute. Additionally, Physical Types are hierarchical.

The MQ Queue Manager Physical Type (ComMQSoftwareWebSphereMQQueueManager) is the parent of the Local Queue Physical Type.

This is necessary because you could have a Queue called X on QM1 and another queue called X on QM2 and TrueSight Middleware and Transaction Monitor must be able to distinguish between the two. Thus, the fully qualified Topic for the current depth of a queue is ComMQSoftwareNetworkHost!ComMQSoftwareWebSphereMQQueueManager!ComMQSoftwareWebSphereMQLocalQueue!CurrentQDepth. When a data point is published (say Current Depth of the Q called X on the Queue Manager called CSQ1 on the system MQA), it is assigned the Topic Path as above, an Instance Path (MQA!CSQ1!X!CurrentQDepth) and a Value. This information is published to the Topic Service and can be read by one or more subscribers.

TMTM Application Service and Oracle

If you use an Oracle database with the TMTM Application Service and your service log indicates it is unable to find the Oracle dll, you might need to use the logon ID that was used to install the Oracle client to start your TMTM Application Service as a Windows service.

To use the logon ID

  1. Open the Services list in your Windows Computer Management page.
  2. Right-click on TMTM Application Service and select Properties.
  3. Open the Log On tab and select This account.
  4. Enter the account credentials used to install Oracle client on the services computer.

Note

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

To avoid timeouts and JVM restarts set:

wrapper.ping.timeout=t

where t is the number of seconds

TMTM Event Service

The TMTM 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 WebSphere MQ queue
  • Send an SQL message to a WebSphere MQ queue
  • Send a message to the Tivoli Event Console
  • Send a message to HP OpenView
  • Send a message to BMC Event Manager (BEM)
  • Delete a transient topic
  • 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 TMTM 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 TMTM Topic Service and on to the TMTM Event Service. The TMTM Event Service determines if any events have occurred based on the rules and templates. If so, the TMTM Event Service takes action, which could involve the TMTM Client Gateway Service or the database (depending on the type of action).

The Event Service can be configured to subscribe to any subset of the monitored properties. This is done using a trigger condition. A trigger uses an object called a Typed Topic (TT in the diagram) that enables you to select the properties that are needed to detect the particular event condition. The Trigger diagram is then wired using standard calculation (such as, multiply, divide, and add) and comparison operators (such as, less than, greater than, and equal to), as well as Boolean logic (AND, OR) to define the condition. The final flag has a Duration property, enabling you to specify that the condition must remain true for some time before triggering the event.

Once a Trigger condition is met, then the actions defined in the Action Pipeline are performed. An Action Pipeline consists of one or more actions (selected from a broad list of types, such as email, Write to File, Write to Q, Send to BEM) wired together. Subsequent actions can be taken depending on whether the previous action succeeds for fails.

Finally, all TrueSight Middleware and Transaction Monitor Events are based on templates. The Trigger condition is generic for all objects of the same type. An Event Template joins together the generic Trigger with the corresponding Action. You then associate all specific objects of the type with that template to have the event condition evaluated against them.

Example

Message Dequeue Rate = 0 and Current Depth > 0 is a condition that would be evaluated for many different queues. 

There is one “Messages Not Processed” Event Template that can be associated with one or more queues. 

TMTM Client Gateway Service

The TMTM 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.

TMTM ProactiveNet Service

The TMTM ProactiveNet Service publishes TrueSight Middleware and Transaction Monitor (TMTM) monitored data to TrueSight Infrastructure Management or ProactiveNet that wouldn't otherwise be available to the products. As updates arrive at the TMTM 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.

Similar to the History Service data, you might want to send the values of specific attributes to ProactiveNet or TrueSight Infrastructure Management for dynamic baselining. To do this, there is an Enable ProactiveNet column next to each attribute in the History Template. Checking that box causes the ProactiveNet Service (rather than or in addition to the History Service) to subscribe to that topic. The ProactivNet Service then sends the data to ProactiveNet or TrueSight Infrastructure Management through a PATROL Agent.

To enable this integration to function, the following conditions must be satisfied:

  • You must be using TrueSight Infrastructure Management 9.6 or later or ProactiveNet 9.0 or later.
  • The MTM KM must be installed in a PATROL Agent. See Installing for details.
  • The objects that need to send data to TrueSight Infrastructure Management or ProactiveNet must be associated with a history template or rule.
  • The Enable ProactiveNet flag must be set for the history template or rule for the objects that are associated with it to send data to ProactiveNet. See Defining data rules and templates for more details.

Note

 In releases prior to TrueSight Middleware and Transaction Monitor 7.0, the TrueSight Middleware and Transaction Monitor integration with ProactiveNet reported all TrueSight Middleware and Transaction Monitor agent hosts in a hierarchy under the host where the MTM KM was running, which is no longer the default behavior. Versions 7.0 and later allow agent nodes, and any monitored objects below them, to be reported as a Top Level Device in ProactiveNet (Device Consolidation feature). This capability enables ProactiveNet to correlate the metrics from TrueSight Middleware and Transaction Monitor together with any other metrics collected by KMs on those nodes. This behavior is the default for all new installations and for upgrades before configuring the TrueSight Middleware and Transaction Monitor integration with ProactiveNet. This avoids changing the reporting structure for installations that were using the integration before TrueSight Middleware and Transaction Monitor 7.0 was released.

If you are using the old device reporting structure and are upgrading, and want to change to the new device reporting structure, perform the following steps:

  1. Stop the TMTM ProactiveNet Service.
  2. Edit the services.cfg file in the base installation directory.
  3. Find the ProactiveNet_Service stanza.
  4. Look for an entry like: show_bmtm_agents_as_top_level_devices=false
  5. If the entry exists, change false to true
  6. If the entry doesn't exist, add it as follows: show_bmtm_agents_as_top_level_devices=true
  7. Start the TMTM ProactiveNet service. 
Was this page helpful? Yes No Submitting... Thank you

Comments

  1. Nikhil Shetty

    Link for 'Defining data history rules and templates ' hits to a blank page , please fix this .

    Aug 21, 2018 06:33
    1. Ashley Pearson

      Hi,

      Thanks for your feedback, the link was fixed!

      Aug 21, 2018 06:51