You may be wondering what all these sensor options are. TADDM now has script-based sensors, Asynchronous Discovery(ASD) sensors, and the original 'legacy' sensors TADDM always provided. How do you choose which to use? This has been an important topic with one of our TADDM customers lately and I thought it would be worth sharing the information I received below from development.
First let me describe each one;
Legacy sensors : these are the java based sensors that have always come from TADDM and the default option for discovery, they are run on the TADDM discovery server.
Script-based sensors: where discovery logic (the script) is separated from parsing/transformation logic (java/jython), but the scripts are launched from a sensor on the TADDM discovery server.
ASD: this is the same as script sensors but they are run manually on the target and the results are transferred to the TADDM discovery server for processing.
In general, script-based discovery has advantages over the legacy java sensors, there are exceptions which I will note below the ones I know about. The advantages are;
1) script sensors are fairly simple and are written in platform shell scripting languages (sh(*NIX) and powerShell (windows)) and hence:
- the user can review all the commands that are going to be executed on discovery target
- the user can even change script commands as long as the output is unchanged (e.g. add sudo) - although he will be required to merge manual changes when TADDM is updated
You can view the scripts in the appropriate sensor sub-directories under $COLLATION_HOME/osgi/plugins/ on your TADDM discovery server.
2) sensors scripts can be extracted into separate independent package and run outside taddm discovery (Asynchronous discovery) - on the targets where direct access from TADDM is not possible due to connectivity or access issues. That also generates another interesting possibilities)
2.1) sensors scripts (ASD package) can be send to the host owners when they are not able/willing to provide credentials
2.2) sensors scripts (ASD package) can be send by TADDM independent host access methods (e.g. using IEM to perform ASD discovery without need for any credentials and scopes in taddm)
3) script based sensors are transferable via 'discovery over ITM infrastructure' - for non-scripted ones this is possible only for sensors using SSH access (typically that is limited to Level2 sensors - but not always).
4) Script based discovery forces developer to use shell commands and/or parse configuration files (which required OS level credentials) instead using native protocols (e.g. JMX) which typically are requiring Level3 credentials (non-OS).
The Websphere sensor is a good example of sensor change that with move from JMX to script based benefits from all 1-4 above. It can work now though ITM, and require only OS level credentials just to be able capture some files. A number of customers use the Websphere script based sensor because getting Websphere access is much more difficult then just OS file access.
However, Oracle sensors on the other hand benefits from 1-3, but as for the 4th - the trade off done in the sensor today is that the legacy sensor requires internal oracle user (via jdbc) but the script sensor requires not just the OS-level account user but also the Oracle 'instance owner' user(owner of oracle_home). This is a fairly rigid requirement that some users may not have access to. So in this case, the Oracle sensor in script mode actually has tighter credential requirements. You can read more about this here:
https://www-304.ibm.com/support/entdocview.wss?uid=swg1IV57766 So depending on your environment, the Oracle script sensor may not be the best option.
Although scripted versions of sensors tends to have more advantages over the 'legacy' approach there are still certain technology limitations e.g. network devices, appliances and some application which are not allowing script approach to be used, so although scripted approach is the preferred one whenever possible still some sensors will continue to use 'legacy' approach due to these technology limitations. In order to determine which sensor has a scripted option please refer to the TADDM sensors guide here;
http://pic.dhe.ibm.com/infocenter/tivihelp/v46r1/index.jsp?topic=%2Fcom.ibm.taddmsensors.doc_7.2.2%2FSensorGuideRef%2Ft_cmdb_sensorguideref_parent.html
If a sensor supports scripted discovery, it will have a sub-section "Asynchronous and script-based discovery support" which lists the support level, configuration and access requirements and known limitations. This information can help you decide if the scripted version of the sensor is a good choice for your environment.
So, like I said above, the 'legacy' sensors are the default, but where possible scripted sensors are preferred as long as you understand the limitations. If you want to get started switching to the scripted sensors, here is a link to the configuration options;
http://pic.dhe.ibm.com/infocenter/tivihelp/v46r1/index.jsp?topic=%2Fcom.ibm.taddm.doc_7.2.2%2FAdminGuide%2Ft_cmdb_configure_script_based_discovery.html
I would like to hear comments on this post, what sensors are you using?, have you tried script sensors vs. legacy?, which one do you like better?
Thanks!
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSPLFC","label":"Tivoli Application Dependency Discovery Manager"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]