Configuring the sensor

Before running a discovery, you must configure the custom template sensor.

The custom template sensor is not enabled by default. To enable the sensor, you must create a discovery profile and then enable the sensor in the new profile. You must also enable in this profile any additional sensors that you want to analyze the results from.

You must create a template for the custom template sensor. This template consists of the following files:
template.xml
This file contains the configuration data. In this file, you specify the TADDM result class object that you want to analyze.
matcher-script.py
This script extracts the specified model objects that are then processed by the sensor-script.py file.
sensor-script.py
This script can modify objects, create model objects, and store model objects.
You must place these files in the $COLLATION_HOME/etc/templates/cts/template_name directory. The name of the directory template_name must match exactly the name as specified in the template.xml file.

To run the discovery, read access rights to the templates directory and its associated files are required.

The scripts are Jython scripts. See the SDK Developer's Guide for information about the custom server extensions API. General script-related information in this guide can be applied to the custom template sensor scripts. Detailed information about code related to initializing the environment, importing TADDM sensor tools, and logging errors can be used when defining the sensor scripts. All script files must be placed in the $COLLATION_HOME/etc/templates/cts/template_name directory.

Template.xml

The template.xml file has the following structure:
<CTSTemplate>
	<name>template_name</name>
	<result-class>com.ibm.cdb.discover.app.db.db2.result.Db2Result</result-class>
	<plugin-id>com.ibm.cdb.discover.sensor.app.db.db2.db2_7.6.0</plugin-id>
	<engine-id>com.ibm.cdb.core.jython253_2.5.3</engine-id>
	<matcher-script>matcher.py</matcher-script>
	<sensor-script>sensor.py</sensor-script>
</CTSTemplate>
Fix Pack
8In the above example, the template specifies that the Custom Template Sensor needs to run after the sensor defined in the plugin-id tag (DB2 in this case) has generated the result to be analyzed.
Important: You must arrange the elements of the template.xml file exactly like in the preceding example. Otherwise, errors are generated.
name
The template name. For example, if the template name is example_template, then you must have the directory structure: $COLLATION_HOME/etc/templates/cts/example_template.
result-class
The fully qualified name of the TADDM result class that you want to analyze.
plugin-id
This plugin-id specifies the ID of the plug-in that provides the results. This ID is required for pluggable sensors only.
engine-id
This engine-id specifies the IP of the plug-in that provides the Jython engine to be used, for example com.ibm.cdb.core.jython253_2.5.3. If not specified, the default engine is used.
matcher-script
The name of the Jython script (.py extension) that lists all of the objects that meet the criteria defined in the script.
sensor-script
The name of the Jython script that processes the list of objects generated from the result-matcher script. Depending on the object returned the script modifies the objects or creates new objects. These objects can then be stored.

Matcher script

This script is run when the result object of the class specified in the template is discovered. The following information is provided to the script from the sensorhelper code:
  • The ResultMap is a map of the model objects, their arrays, or collections. These objects are the shared properties of the result object that are matched by the template. The map is indexed by property name.
  • The ReturnList contains a list of elements that require further processing. Each element is associated with the name that is displayed as the sensor starts for that element.
When the result matcher script completes successfully, this information is used to seed the custom template sensor.

This script example shows the steps that extract objects from the discovery results of the generic server sensor.

# Initialising the environment
import sys
import java

from java.lang import System
coll_home = System.getProperty("com.collation.home")

System.setProperty("jython.home",coll_home + "/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib")
System.setProperty("python.home",coll_home + "/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib")

jython_home = System.getProperty("jython.home")
sys.path.append(jython_home + "/Lib")
sys.path.append(coll_home + "/lib/sensor-tools")
sys.prefix = jython_home + "/Lib"

import traceback

# Importing sensorhelper
import sensorhelper


#  Initialising script input
(resultMap,returnList,log) = sensorhelper.init(targets)
log.debug("CTS result matcher script running")

try:
    #  get runtime processes list from the result
    runtimeProcesses = resultMap['runtimeProcesses']
    # get first of the processes  
    rtp = runtimeProcesses[0][0]
    #  add it to the list of elements that need further processing   
    returnList.add("dummyName",rtp)
    
except:
    log.error("Error occurred")
You can use an XPath query when using the JXPath library to determine which of the objects are returned. The findElementsForXPath function can be used to query and return a collection of objects resulting from the query. The following example finds and prints an IP address using the findElementsForXPath function. See the SDK Developer's Guide for information about this utility function.
result = IpListResult();
ip1 = IpAddressImpl();
ip1.setStringNotation("9.0.0.1");
ip2 = IpAddressImpl();
ip2.setStringNotation("9.0.0.2");
result.list.add(ip2)
result.list.add(ip1)

elements = sensorhelper.findElementsForXPath(result,"/list[stringNotation='9.0.0.2']")
for e in elements:
    print e

Sensor script

This script starts separately for each of the extracted objects returned from the result-matcher script. Depending on the objects returned, the script modifies, creates, and populates the model objects. These objects can then be stored. The following information is provided to the script from the sensorhelper code:
  • The CTSSeed object that contains the ResultMap and the name value pair returned by the result matcher script.
  • The CTSResult object is a custom template result object that is populated by the sensor script with the model objects that can be stored.
This script example shows the steps that populate and store model objects.
import sys
import java

from java.lang import System
coll_home = System.getProperty("com.collation.home")

System.setProperty("jython.home",coll_home + "/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib/jython-2.1")
System.setProperty("python.home",coll_home + "/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib/jython-2.1")

jython_home = System.getProperty("jython.home")
sys.path.append(jython_home + "/Lib")
sys.path.append(coll_home + "/lib/sensor-tools")
sys.prefix = jython_home + "/Lib"

import traceback
import sensorhelper

(ctsResult,ctsSeed,log) = sensorhelper.init(targets)

log.debug("CTS Sensor script running")
#  get value passed by result matcher
runtime_process = ctsSeed.getSeedInitiator().getValue()
#  get name passed by result matcher
name = ctsSeed.getSeedInitiator().getKey()
templateName = ctsSeed.getTemplate().getName();
log.debug("CTS Sensor script running for template " +templateName + “/” + name)
#  process runtime process with user defined function
result = processRuntimeProcess(runtime_process) 
#  return resulting model object
ctsResult.addExtendedResult(result)
Fix Pack
8Besides the above example, a more common scenario is to fetch data by running commands directly on the target using methods sensorhelper.executeCommand or sensorhelper.executeCommandWithTimeout and then store the output result in the extended attribute of the model object.
The following code snippet added in the matcher and sensor-script for instance obtains the version for a Jboss product.

#  Matcher script snippet:
#  add all results of resultMap (not filtering) to returnList
returnList.add(sensorName,resultMap)      
#  Sensor script snippet:
#  get the appServer model object from value passed by result matcher
initValue = ctsSeed.getSeedInitiator().getValue()
server = initValue.get('appServer')
if str(server) == 'None':
              server = initValue.get('domain')
os = sensorhelper.getNewOsHandle(server.getContextIp())
#  execute command on jboss target (os) and fetch version
versionResult = sensorhelper.executeCommandWithTimeout("cat /opt/Jboss/EAP-7.1.0/version.txt | sed '/^$/d'", 100000, os)
#  set extended attribute ProductVersion’ in appServer or domain model object
sensorhelper.setExtendedAttributes(server, {'ProductVersion': versionResult})
ctsResult.addExtendedResult(server)

Fix Pack
8In the above example, before running the CTS sensor, an extended attribute named 'ProductVersion’ must be defined for the appropriate model object type on the TADDM Data Management Portal (DMP). For more details, refer to Creating extended attributes in Domain Management Portal.