Datasource Discovery Filters

Active Discovery filters simply control what objects are discovered for monitoring on a device.  They can be found in the Active Discovery section of multi-instance Datasource templates, and they specify a set of conditions that the object must satisfy in order to be discovered.  From everything found by Active Discovery for a datasource, only objects that satisfy the filter criteria will be added into monitoring.  You can customize discovery filters to stop LogicMonitor from causing too much noise on non-critical infrastructure, but still provide the data and alerts you need.

An example: we don’t usually care about monitoring the state of down interfaces, so the Interfaces datasources have a filter:

This simply means that when walking the table of interfaces via SNMP, each discovered interface also has the interface status OID queried. That status must be a “1” in order for the interface to pass the filter and be discovered. So interfaces that are down, or in testing, will not be discovered, thus not cluttering up the device with interfaces you don’t care about.  (And as Active Discovery runs periodically, if you bring an interface up later, it will pass the test, and be monitored.)


What if I want to still monitor the instances I am filtering out, just with different alert thresholds?

For example, lets say you have a Cisco switch where uplink ports are consistently labeled "Uplink" in the switch port description and Edge ports are not labeled, and you're primarily concerned with alerts related to the uplink ports.  You could add datasource discovery filters to the interfaces datasource that uses the interface description to ensure that only uplink ports are discovered and monitored.  However, lets say that you would still like to monitor the edge ports, but with different alert settings.  

In this case you should clone the interfaces datasource twice (because the standard Interfaces datasource applies to all devices that respond to SNMP, but we only want to apply the extra filtering to our network gear), to end up with three datasources instead of one: one that applies to Cisco devices, and only discovers uplinks; another that applies to Cisco devices and discovers everything not an uplink, and one that applies to everything else (the original).  Here is the process you'll need to follow:

1.  Clone the Interfaces (64 bit)- datasource - make sure to give the new cloned datasource a descriptive name (e.g. Interfaces (64 bit) Uplinks)

2.  Edit the applies to for the cloned datasource such that it only applies to Cisco devices:

What if I want to still monitor the instances I am filtering out, just with different alert thresholds?

3.  Add a discovery filter so that only uplink ports are discovered.  If you use “Uplink” in the interface description, you can follow the example below, but there are many other ways that this could be done:

(How did we know that returned the interface description (technically, interface Alias) as a string?  In this case, it was used in the Active Discovery section as the Description field, so it was apparent, but otherwise we would have had to look it up in a MIB browser.)

4.  Now we have a datasource that discovers only uplinks. If we want to also monitor non-uplinks, we can repeat the process: clone our new datasource, name it Interfaces (64 bit) Edge Ports, set the Applies To to IsCisco() and then set the filter to the inverse. e.g. instead of Contains Uplink, use the filter NotContains Uplink.

5.  Adjust alert settings on the Edge Ports datasource by removing the threshold on the Status and StatusFlapping datapoints

6.  Finally, we need to prevent our regular Interfaces datasource from monitoring these interfaces as well. This is easily achieved by setting the Applies To field to “hasCategory(“snmp”)&& !isWindows() && !isCisco()” (i.e. apply this datasource to all devices that support SNMP, but not Windows devices and not Cisco devices.)


Other Discovery Filter Use Cases

  • Discovering QA volumes on storage arrays differently from Production volumes, so they can automatically have different thresholds
  • Automatically classifying VIPs on a load balancer