Shallow Software Server Discovery
There are scenarios where level 2 (OS account) credentials are provided, but level 3 (software account) credentials are not provided. In this scenario, the level 3 sensors will fail and there will be no detail discovered for those software servers (e.g. WebSphere, Oracle). To get some detail of software servers during level 2 discovery, you can create custom servers that launch according to the level 3 sensor criteria. This will provide some information about software servers including IP and port, run-time, and, most importantly, relationships and dependencies.
Note that lsof/netstat/ps must be functioning properly for this strategy to work.
First, query all the existing templates in TADDM (both sensors and custom sensors) using the following command.
sdk/bin/api.sh -u <user> -p <password> find -d 5 com.collation.platform.model.discovery.template.Template > ~/templates.xml
This allows you do inspect the template that the sensors use, so you can use the same criteria for your custom server. For Oracle, we see the following template.
For boolExp, 1 is OR and 0 is AND when identifying the criteria.
Continuing with the example (Oracle), we can create the following custom server definition (that matches the sensor template).
Note that, for Type, always use DatabaseServer, J2EEServer, WebServer, or AppServer when creating custom servers.
Now, you can disable the Oracle sensor (if applicable) and enable the CustomServerSensor in your discovery profile. Assuming lsof/netstat/ps is successful, the custom server Oracle should trigger and discover basic details, including dependency information.
If later, the level 3 sensor is run on top of this, it *should* merge based on the IP/port matching, though you should test this in development before implementing the specific level 3 sensor.