Application Dependency Discovery Manager

Home > Sensors > Sensors Best Practices

Sensor Best Practices

To learn more about the TADDM Sensors and Reports Community and how you can contribute, click here. This is a Community page, and anyone can contribute. Sign in in to the wiki and begin contributing to the TADDM Sensors and Reports Community.

This page includes best practices for using IBM® Tivoli® Application Dependency Discovery Manager (TADDM) sensors.

Filter Criteria for Sensors

Selecting "Custom Servers" button in the Discover UI shows the list of all matching templates which have been loaded. TADDM's built in sensors use this same matching facility but are hidden from this view. This screen allows new matching criteria to be entered for a sensor or for existing matching criteria to be edited.

In the add/edit dialog box, any number of matching rules may be entered. These rules are combined with either logical AND or logical OR as specified by the radio button in the dialog box. For more complex conditional logic and grouping, regular expressions may be used. The "regular-expression" option is not immediately apparent, scroll down the drop down box to see it. The regular expression entered is passed verbatim to the java.util.regex library functions.

Importance of Order in the Custom Server list

The matching templates are applied to runtime processes in the order they appear in the list. The hidden criteria for the built in TADDM sensors are applied first. Since the order is important, the most specific templates should be first, followed by more general templates. Pay particular attention to the "JavaServer" template bundled with TADDM. It is very broad. Consider disabling it. Potential match condition collisions are best avoided by matching templates which use the "arguments" and "Windows Service Name" attributes and the "regular-expression" or "ends-with" matching operator.

Server Processes

TADDM applies the Custom Server matching templates only to "server processes". These are processes that are either listening on a TCP port or are Windows Services. One can force a particular program name to always be considered a server whether it is listening or not using the following properties in collation.properties:

com.collation.platform.os.UnixOs.forcedServerList=
com.collation.platform.os.WindowsOs.forcedServerList=

Care must be used when adding a program name to these properties. First, adding a very common program such as "java" or "bash" would cause many processes which are not servers to be considered server processes. Second, forced servers have their listen port set to zero. Special handling via Custom Server Extension (see Chapter 9 of the TADDM User Guide) must be used to set AppServer.keyName to something unique to prevent all forced servers on the same machine to be merged into one object by the storage engine. If the application contains listening and non-listening components, consider using sensorhelper.getPidPortList() (see TADDM SDK guide) to discover the non-listening components rather than the above properties.

Discovering Multipart Applications

There are many ways applications can be constructed and deployed. TADDM provides a number of ways to discover and group the various components.

• Discover one of the major components as a proxy for the rest. This is how TADDM's built in sensor tend to work although there are exceptions. Discovering all the components can be interesting at a micro level but from a macro level perspective this is often not necessary or desirable. The sensorhelper.addProcessToPool() library call can be used to add many component processes to the process pool for a single AppServer instance. This allows TADDM to use the relationships of all the components to construct the relationships of the whole.

• Discover the various components as AppServers. This can be done either by having multiple matching templates or multiple matching rules in a single template or combinations of the two. Additionally, a single template could be made which discovers multiple AppServers by using sensorhelper.newModelObject() and result.addExtendedResult() (see Chapter 9 of the TADDM User's Guide). These AppServers, however they were created, can be grouped into a Business Application either by using an Application Template or AppDescriptor. Of the two options, AppDescriptors are by far the most flexible and are the preferred solution.

Open Source

Sensors should not contain open source. If you find a need to include open source in your sensor, click here and provide your feedback.