Efficient Discovery

Efficient Discovery

Customizing Trigger TQL is one of the quickest and easiest ways to extract efficiencies from any Discovery job in HPE UCMDB. Each out-of-the-box (OOTB) job has been tailored by Effectual to trigger on specific CI types, which have been tightly qualified to target desired nodes with appropriate protocols. The outcome is a Discovery process that can run efficiently and effectively, eliminating false error messaging, wasted effort, and unnecessary overhead.

The OOTB Trigger TQL for Host Connection by Shell triggers on intended targets but does not filter out nodes which were previously discovered, inventoried and qualified. Much Discovery time can be wasted when using this trigger, once you start gaining maturity in your CMDB, by touching CIs that already exist.

Customized Trigger TQL can be made more efficient than what is available OOTB. This efficiency will save the time typically spent executing Discovery on previously qualified nodes, and eliminate the additional network overhead created by the unnecessary connections. There are many improvements that can be made to Discovery beyond customizing Trigger TQL, but this is definitely one of the easiest ways to gain value.

 

Other ways to customize Trigger TQL and Discovery:

  • Break up large numbers of triggered nodes into smaller parts
  • Limit a Discovery job to a subset of the whole
  • Separate jobs by region or time zone
  • Assign a particular job or jobs to a specific probe or set of probes

Read on for more information on how to make Discovery smarter and more effective by reducing waste—a common tenet of Effectual’s best practice.

 

The rest of this blog covers Effectual’s best practices for customizing trigger TQL, CI Type inputs, and input queries (as well as briefly explaining the rationale for each our modifications). Each section will walk the reader through the steps in creating their own customizations using examples. Examples and directions are taken from UCMDB 9.05 but the concepts illustrated are relevant to other versions.

Note: Readers should have some prior knowledge of Discovery, TQL, and how to navigate the Discovery control panel. We recommend that all preliminary work be performed in a test environment where impact of changes can be observed, and unwanted outcomes can be eliminated through an iterative process.

 

1. Creating a Custom Module

Creating a custom module is essentially the process of creating a container to hold your customized Discovery jobs.

A. Click on the  icon and select Create New Module.

B. Type in the name of the module (e.g. Africa Europe – Start 1pm End 12am).

Discovery Module Name

 

 

 

 

2. Creating a new job by copying an existing job

It is always a good idea to copy an OOTB job and customize the copy (rather than the original). The original can then be used for reference material, backup, and/or replacement in case irreparable damage occurs in the copy.

A. Right click the desired job and select Save As.

 

 

 

 

 

 

 

B. Enter the new job name.

 

 

 

C. Right click on the new job and select Move To.

D. Select the Module you previously created in section 1 and click OK.

 

3. Customizing Trigger TQL only

Customizing Trigger TQL is one of the quickest and easiest ways to extract efficiencies from Discovery. As long as the output node of the Trigger TQL query remains unchanged, this type of customization can be the only one you make. However, if the output node of the Trigger TQL is changed to a different CIT, all of the changes detailed in section 4 through the end of this document are necessary for the proper function of a job.

Host Connection TQL

The above illustrates the OOTB Trigger TQL for Host Connection by Shell. It triggers on desired targets but does not filter out IPAddress CIs related to nodes which were previously discovered, inventoried and qualified.

The above, in contrast, illustrates a custom Trigger TQL for the same job. It will only trigger on IPAaddress CIs that do not have a relationship to a qualified node. Note that the output node (IpAddress) is the same in both examples. The custom Trigger TQL is more efficient than its OOTB counterpart; it saves the time typically spent executing Discovery on qualified nodes and eliminates network overhead created by the additional connections.

Note: For a full set of instructions on how to customize Trigger TQL, refer to section 5.2.

Other ways to customize Trigger TQL and Discovery:

  • Break up large numbers of triggered nodes into smaller parts
  • Limit a Discovery job to a subset of the whole
  • Separate jobs by region or time zone
  • Assign a particular job or jobs to a specific probe or set of probes

 

4. Customizing CIT Input

Customizing the CIT input for a specific job can minimize the number of servers or CIs a job targets, eliminating overhead and error messages created by attempts to connect to a node with an inappropriate or incorrect protocol.

A. Select the job you want to modify and under the Details tab, click Edit Adapter.

B. In the Input pane, next to Input CI Type, click  and select the CIT related to the job.

The image above shows the change in the Input CI Type from Shell to Unix; the goal of the change is to eliminate other devices using the Shell protocol (e.g. Windows nodes and network devices) from being targeted by the Discovery job since we are only interested in Unix & Linux nodes.

Note: The remainder of this document will continue using this example.

 

5. Customizing the Input Query

Once the Input CIT is changed, the Input Query and Trigger TQL must be changed to match the Input CIT for the related Discovery job to run properly.

A. In the Input pane, click on to edit the Input Query. Below is the original Input Query.

C. The Input CIT will always need to be named SOURCE. The image above reflects the OOTB Input Query which uses the Shell protocol as the SOURCE. To match the Input CIT changed in section 4., double click on the Node CIT and change the element name to SOURCE.

D. Next, change the name of the Shell CIT to HOST by double clicking on it and changing the element name.

E. Shown below is the Final Input Query. Essentially the SOURCE and HOST element names have switched places.

 

5.1 Changing the Trigger CI Data to match the Input Query

The Triggered CI data must be modified in order to pull the information from the correct nodes in the Input Query. This is how the discovery script gets information for authentication and discovery. Since the nodes in the query have swapped names, the strings in the Triggered CI data fields must be modified to match the changes made in section 5. Below are the OOTB strings:

A. Change all the values to match the Input Query by changing the strings to point at the correct node. In this case, HOST refers to the Shell CIT from 4. E.

B. Click Save to save the changes.

 

5.2 Customizing the Trigger TQL

Trigger Queries qualify CIs and focus Discovery by narrowing triggers to desired targets only. By changing the trigger CIT, you are telling the Discovery job to target specific CIs (e.g. Unix only). Trigger TQL will also need to be updated to reflect any changes made to Input CIT from the previous sections.

A. Click on the Properties tab for the job you wish to modify.

B. In the Trigger Queries pane, select the Query Name, and then click  to edit the TQL.

C.Below is the original TQL, which has a Shell agent connected to a Node. This TQL will trigger all nodes that have a relationship to a SSH agent and will include undesired results:

 

 

 

 

 

 

 

 

 

 

D. To target only Unix servers, we need to change Node to Unix.                

E. Click OK to save the TQL.          

F. Verify that your trigger CIT is the only CIT in the Trigger TQL that is not hidden; doing so makes it the output node of the Trigger TQL. To hide a CIT, right-click on the CIT and select Hide Element in Query Results.

             

G. The box on the right side of the CIT denotes that the CIT is hidden.

             

 

6. Limitations

Customized jobs should be rebuilt any time changes to OOTB jobs (such as those made by installing a new Content Pack) occur, regardless of whether or not a Content Pack changes the underlying structures (scripts, etc.) of the customized jobs. Doing so can avoid unintended or unforeseen consequences.