Troubleshoot Tomcat Pattern discovering WAR files without names - Product Knowledge

Troubleshoot Tomcat Pattern discovering WAR files without names  Get Well Knowledge Article

Troubleshoot Tomcat Pattern discovering WAR files without names

A guide for how to remediate CMDB data

through Discovery Pattern diagnosis and adjustment

Troubleshoot Pattern creating applications without names

Review Pattern Logs to determine why Configuration Items are being created without names

This article is a continuation of KB0829852 where Config Items of Class cmdb_ci_app_server_tomcat_war are being created without names.

Required tasks

Goal: Open the Pattern Logs for the CI Class with recently created Config Items lacking names

Easiest Path: Walking from a Web Application to the Host’s Discovery Status

Start from a Tomcat War file with no name. (Previously located in the example from KB0829852 ) You can open the Tomcat Server record using links within the Relationships Formatter.

1. Scroll to the Related Items section

2. Click on the Contained by – Tomcat instance

3. When the Tomcat record opens, scroll again to the Related Items section

4. Click on the Runs on – Linux or Windows Servers record

5. When the Host record opens, first make a note of the IP Address of the host. We might need this later, if the Logs aren’t available in Step g.

6. Scroll to the Related Links and click on Show Discovery Events .

7. On the next page, you may see that Discovery Status histories are not available. (No records to display) There may actually be Discovery Pattern Logs available, but you should use a tool provided below to help locate them.

See the KB Article KB0832844 to install the Discovery Pattern Diagnostic View if you have no discovery events records here. You will need to make note of the Created timestamp for your record so that you can open the correct Discovery Pattern Log entry later on.

Example: If you see this, you should consider installing the Discovery Pattern Diagnostic Tool to help locating log entries that are between 31 and 90 days old.

8. If records are present, sort them by Discovery status in reverse (A-Z) to see the most recent ones near the top

9. Open the most recent record by clicking on the Discovery status number

10. After the form loads, scroll down to the Related List for Discovery Log

11. Sort the Logs by Created in reverse (Z-A)

12. Find the Discovery Pattern Log and click the “Here” link to open it.

With a Discovery Pattern Log entry open from clicking the "Here" link, you will be presented with a two-pane display like this:

A note about Discovery Pattern Editing

This example here is for a specific situation where there are additional rows of data being collected which need to be filtered from the output of our Discovery Pattern These steps are provided as an example means to correct a specific issue within a specific Discovery Pattern

We believe these steps and the embedded notes should be helpful in learning how to diagnose pattern problems in relation to incomplete records

Care should be taken to thoroughly test any change to a Discovery Pattern

Play 3 Steps (continuing within the Discovery Pattern Log viewer)

1. Scroll to the bottom, on the left-hand side, looking for Creating Relations

2. Click once on Creating Relations to focus the reading pane on that section of the logs

3. Confirm by reading within the logs (on the right-side) in the reading pane, looking for related entries matching our CI Class. (which was cmdb_ci_app_server_tomcat_war)

These are the CI Relationships that we “walked” through above using the Relationship Formatter on the Form Views for each Config Item 4. Open the “http and AJP identification” section (by clicking on the [+] icon) which is where the Pattern Logs for each of the Steps executed are located.

5. Use CTRL-f to open search for your browser and then enter our table name. The pattern step should become highlighted which reads “populate CLASSNAME”.

6. On the left panel, click the step to select it. Review the log output in the right side (reading pane) to confirm entries with name= and no value present.

7. Make note of the Step name here, which is “Populate cmdb_ci_app_server_tomcat_war”. We will need the step name to find the proper place within the pattern designer to make our adjustment.

8. Open this pattern within the designer. The easiest way from here is:

a. Scroll to the top on the left-hand side

b. Click on the title of the identification section once to select it

c. Use the debug button to open the pattern within the designer

9. Once the designer opens, either start a debug session if you have a MID Server and permission to debug live, or else continue to the next step. The steps below are listed without the need to have a debug session, which is faster when you know exactly what you need to do. In real life, a debug session makes pattern editing easier since variables are present and populated.

10. Scroll on the left to the step name we noted earlier which is “Populate cmdb_ci_app_server_tomcat_war”. Click on the step name to select it.

Steps are only numbered in the Pattern Designer

Adding / Removing Steps will automatically change their numbers

Logging output is not numbered, so step names are important to debugging 11. Read the following step / operation with the configured parameters to understand what it is doing. In this example, the Parse Variable operation is reading a list of applications to fill in rows for the cmdb_ci_app_server_tomcat_war table.

A few things can be observed from this example:

Because the name of the table variable being populated is a CI Class, these are written to the CMDB with the values in that variable: $apps – this is where our nameless records are coming from! This table has 3 rows (not pictured – we can infer this from the logs) 2 of the rows have empty names while a single row has an accurate, complete record An effective means to remove rows missing a name would be to Filter the table variable to remove incomplete rows

12. Click on the New Step Above icon to insert a step to filter out incomplete data. An Untitled Step will be inserted above the step we had noted previously.

13. Fill in the step and operation as pictured below.

a. Give the step a name

b. Choose Filter Table from the Operation drop down

c. Set “$apps” to be both the Source AND the Target table (case sensitive)

d. Indicate which rows to keep by filling in the single condition as shown

Variable Condition $apps[].name Is Not Empty Example:

What this step is doing

This step and selected operation, when configured as shown above, is such that:

If the name column within any row of the $apps table variable is NOT empty, we should keep that row

Any row where the name is blank will get filtered out

Note that this is only appropriate in this situation because the correct data is also discovered and we only need to remove extraneous rows of data

For more details on tabular/table variable notation consult the documentation

Testing and Promotion / Publish

14. If you have an active debug session, you may test the step using the 'test' button in the top right corner.

15. Be sure to Save and Publish the pattern for it to take effect, and to capture it within your Update Set.

16. Issue a Quick Discovery against the IP Address we noted for our host.

17. Confirm that no additional records for this CMDB class are created where name is empty as a result of this Quick Discovery.

Note: Any change to a Discovery Pattern should be tested well before it is Published and/or promoted to a Production environment!

Congratulations, you have reached the end of this example guide to Discovery Pattern Development.