Application Discovery with DX Unified Infrastructure Management

Having any form of application discovery can be of great benefit. With these capabilities, you can determine what is deployed within your infrastructure and better understand what monitoring to apply to each device. When you know which applications are running within your environment, you can group devices by their associated applications. Once you’ve established these interrelationships, you can start to create monitoring policies for each application and apply those policies at the group level. These capabilities even set the stage for a zero-touch monitoring model in which, when new devices are deployed, they can automatically be added to existing application groups, along with all monitoring policies associated with those groups. 

DX Unified Infrastructure Management (DX UIM) offers an open approach to automated application infrastructure discovery, which means you can add your own scripts for discovering additional information. This even extends beyond applications; you can discover virtually anything about a device. With these insights, you can more intelligently group devices and define monitoring profiles. 

To do application discovery, DX Unified Infrastructure Management (DX UIM), release 7.90 and later, requires a robot, so the various scripts can be deployed and executed by the spooler (internally known as the “spooler plugins”). Each script should run a single command or series of commands to gather the information required. The script will output a set of key-value pairs to “stdout.” The spooler reads in the key-value pairs and creates an entry in the “niscache” directory. These entries are picked up by the discovery server and a new device attribute is created for this device. These device attributes can be used as the filter criteria for operator console groups, employing the advanced option or a SQL statement. Application discovery leverages existing functionality in niscache, plus spooler plugins. 

Each script is contained in its own DX UIM package and can be found in the archive. Let’s look at one of the out-of-the-box scripts to show how easy it would be to write your own. For example, here is the “app_disco_iis_server” package:

Figure 1: Notice the paths of both files point to the plugins/attr_publisher directory. The plugins directory is found in the robot’s base Nimsoft directory.

The “attr_publisher.cfx” file defines the script that the spooler will execute:

The app_disco_iis_server.bat file is the script itself, which is in the plugins/attr_publisher/custom_scripts directory. If we look at the contents of the script, it is a set of commands that will output to stdout:

If the IIS Server application is found, the script will output “Roles=iis_server,” followed by “Finished=true”:

If not found, the script will only output “Finished=true,” which tells the spooler that the script has completed:

Figure 2: Command line examples of running the script where IIS is installed and ISS is not found.

Note: You can run this on the command line to see these results without affecting anything. This will only be counted when the spooler runs.

*** The requirement for the Finished=true has been removed, so you can just return nothing. I have left them in there for backward compatibility. ***

When the spooler runs this script, it will create a new computer system attribute in the “CM_COMPUTER_SYSTEM_ATTR” table. This attribute is padded out, incorporating the script name prefixed by “UserPropMV” to be “UserPropMV.app_disco_iis_server.Roles” with a value of “iss_server”. Devices can have more than one attribute depending on what is installed.

Once the attributes are created, you can create an operator console group based on all the devices that have a specific value. In this case, you can group based on any devices with the value “iis_server.” You can see that the MS IIS Server group has a filter of SQL and a query:

select distinct cs_id from CM_COMPUTER_SYSTEM_ATTR where cs_attr_key like 'UserProp%.Roles' and cs_attr_value='iis_server'

Your query must only return unique cs_id(s) of the devices that have an attribute with a certain value. All these devices can be grouped together for you to apply the specific monitoring profiles.

You can use the same procedure to employ a custom script, even one that has nothing to do with application discovery. In this way, you can gather specific data that’s meaningful to your environment and business. For example, let’s say we want to identify the type of Linux that is running and create a new LinuxType attribute. To do so, you could group by Linux type and set up the monitoring for each type:

Note: This is just an example script and has not been tested on every Linux version.

You can package this script and distribute it via the monitoring configuration service (MCS). This can occur as part of application discovery, and you can specify the frequency and interval to run this script. For this example, it would only make sense to run the script once to get the Linux type, as this will never change.

I hope this gives you a better understanding of the application discovery capabilities of DX UIM and inspires you to write your own scripts. If you have any questions, feel free to reach out if to me in the DX UIM Community.