Eliminate Noise with IECs

Introduction | Preconfigured Scenarios | Extending Preconfigured Scenarios

Exclude Known IP Subnets | Exclude based on Naming Conventions

Exclude Domain Controllers | Exclude Vendor Appliances

Exclude out-of-scope CIs present in the CMDB

Exclude based on any Attributes on the Log Analysis Table

Introduction

Discovery Admin ships with 100s of out-of-the-box IECs.

These out-of-the-box IECs can be further extended or overridden to Eliminate Noise by excluding non-actionable errors from the results of the Troubleshooting, so we can focus on the Devices that need our attention.

This also enables us to eliminate false positives, further increasing the quality of the Troubleshooting results.

This article provides examples and ideas to help understand what it means to Eliminate Noise with Discovery Admin, to further contextualize the results of Discovery Admin to align with the unique nuances of each Customer environment.

The scenarios below may directly apply to your environment or provide the foundation to identify other use cases specific to your environment.

After the scenarios to Eliminate Noise are understood, they can be translated into requirements to Create and Manage IECs and IECMs after we Understand the Troubleshooting Results.

NOTE: All IECs configured to Eliminate Noise, independent of if they are out-of-the-box or extended by the Customer, have the keyword 'Ignore' in their name.

Preconfigured Scenarios

Discovery Admin ships with preconfigured 'Ignore' rules to Eliminate Noise.

These out-of-the-box IECs cover standard use cases that apply to all Customers.

Following are (a subset of) examples of use cases (to Eliminate Noise) that are configured out-of-the-box:

Ignore duplicate Logs due to an incorrect selection of Discovery Status Records while initiating a new Troubleshooting.
Ignore more than one Error on an IP Address that has the same remediation.
Ignore errors on different IP Addresses (that belong to the same Device) that have been successfully discovered via another of its IP Address(es) in the last 24 hours.
Ignore errors corresponding to Credential-less ServiceNow Discovery, if configured but not actively used.
Ignore non-actionable errors on IP Addresses that are being discovered correctly.
Ignore non-actionable errors on IP Addresses that have other, more relevant, and actionable error(s).
Ignore non-actionable errors on IP Addresses responding to more than one protocol, like SNMP Errors on WMI Devices, SSH Errors on SNMP Devices, SSH Errors on ESX Servers, etc.

Extending Preconfigured Scenarios

Examples included in the above Preconfigured Scenarios can be extended to accommodate data specific to the results of Discovery Admin in your environment.

Each bullet in the section above (representing out-of-the-box rules) can be further extended to align with the data, unique to your ServiceNow Instance.

Example 1:

Telecom Devices in your environment may be configured to respond to SSH and SNMP resulting in two error logs corresponding to each protocol.

However, since Telecom Devices are discovered via SNMP, we can ignore the error generated by the SSH Protocol.

In this example, IECs in Discovery Admin can be configured to Ignore the SSH Error.

Example 2:

Devices with multiple Network Adapters often get successfully discovered via the IP Address on one of the Network Adapters, but fail on the other Network Adapters. However, since ServiceNow Discovery successfully worked on one of the Network Adapters, we can ignore the errors on the other Network Adapters.

In this example, IECs can be configured to Ignore errors on the secondary Network Adaptors leveraging the Most Recent Discovery attribute on the CI.

Exclude Known IP Subnets

There may be certain IP Subnets on the network where we can ignore certain protocols, but we still have to scan them to discover other Devices.

While this may be accomplished by revisiting our Design of the Discovery Schedules, this approach is often complicated and may have other downstream impacts that would require additional remediation, especially if many smaller IP Subnets have similar exceptions to the rule.

A Discovery Schedule redesign to address this may also result in a significantly higher number of Schedules, requiring more maintenance and increasing the complexity of the design.

IECs in Discovery Admin can be configured to identify these IP Subnets (or even specific Devices within these IP Subnets) and ignore the related Discovery Logs.

This can be done by leveraging attributes consolidated by Discovery Admin that capture the IP Address and Discovery Schedule Information.

Exclude based on Naming Conventions

In some scenarios, certain Devices are not only out-of-scope for ServiceNow Discovery but are also out-of-scope for the population in the CMDB.

Examples could include equipment on the factory floor that responds to SNMP or dedicated medical devices that respond to SNMP.

IECs in Discovery Admin can be configured to identify these Devices based on the information being returned via the DNS Name and ignore the related Discovery Logs.

This can be done by leveraging attributes consolidated by Discovery Admin that capture the Name of the Device.

Exclude Domain Controllers

It is uncommon to get the credentials to discover Domain Controllers because of the criticality of Domain Controllers and the level of access needed by ServiceNow Discovery to discover them.

Since Domain Controllers have the WMI Port open, they will always fail on WMI Credentials.

However, it is important, that these known errors are ignored and not reported to the Windows Support Team for resolution.

IECs in Discovery Admin can be configured to identify Domain Controllers and ignore WMI Credential Failures on those Devices.

This can be done by leveraging attributes consolidated by Discovery Admin that capture the Name of the Device, along with other attributes that provide inputs confirming that the Device is a Domain Controller.

Exclude Vendor Appliances

It is uncommon to get the credentials to discover Vendor Appliances because they are owned and managed by the Vendor.

Since Vendor Appliances typically have the SSH Port open, they will always fail on SSH Credentials.

However, it is important, that these known errors are ignored and not reported to the Unix Support Team for resolution.

IECs in Discovery Admin can be configured to identify Vendor Appliances and ignore any SSH Credential Failures on those Devices.

Exclude out-of-scope CIs present in the CMDB

It's common to have Devices in the CMDB (which are populated Manually or via a 3rd Party Integration) that are not in scope for ServiceNow Discovery. These Devices may be in a specific CI Class or could have an attribute on the CI indicating that it will not be discovered.

IECs in Discovery Admin can be configured to identify these Devices based on the information already present in the CMDB and ignore the related Discovery Logs.

Example 1:

A CI can have an attribute like Discovery Source = Manual or Category = Appliance or a custom field like Manual Entry = True

Using these attributes on the CI, we can ignore errors on this Device.

Example 2:

A CI Class like Telecom Devices could be imported and maintained via a 3rd Party integration. Using CI Class = Telecom Devices, we can ignore errors on this Device.

Exclude based on any Attributes on the Log Analysis Table

Building on the scenarios above, we can extend our use cases to leverage Discovery Admin to Eliminate Noise.

IECs in Discovery Admin can be configured to look at any attribute (including via dot-walk) on the Log Analysis Table and use that as input to ignore the related Logs generated by ServiceNow Discovery.