Active Discovery

Active Discovery is process that LogicMonitor uses to discover and identify instances for a multi-instance LogicModule. The result of Active Discovery is the identification or one more instances that LogicMonitor can use to collect a particular type of data. 

Instances are organized under their parent LogicModule in the Resources Tree. 

Active Discovery Execution

DataSources with Active Discovery enabled have a discovery schedule that defines the time between Active Discovery executions. This discovery schedule is configured from the DataSource definition and varies per DataSource. For more information, see Configuring Active Discovery.

For example, objects that change less frequently, such as the number of fans or CPUs in a system, are assigned collection schedules of once a day. Objects that change frequently, like volumes on a NetApp disk array, however, are assigned a collection schedule of several times per hour.

The Auto Discovery not only runs according to the discovery schedule defined in the DataSource but also runs when: 

• A resource (or DataSource) is added into monitoring.
• A resource or DataSource’s properties/configurations are changed.
• It is manually initiated from the Resource tree. The ability to manually execute Active Discovery is useful when you have added a new object onto a resource and want to be sure LogicMonitor picks it up immediately for monitoring without having to wait for the scheduled Active Discovery execution. For more information, see Adding Instances.

Information Retrieved During Active Discovery

Active Discovery retrieves the following information for each instance it finds:

• Instance name—The descriptive name of the instance displayed in the Resources tree.
• Instance ID—The ID of the instance, used as the variable to identify this instance when querying the device for data. For example, the variable part of an SNMP OID tree, or the volume ID in a storage system. 
  Note—Your ID must always be unique.
• Instance description—An optional description of the instance, which is displayed along with the instance name in the Resources tree.
• Instance properties—Optional sets of key-value pairs that provide static data about the instance. These are analogous to resource properties, but are collected on a per-instance basis. Once collected, instance properties are stored (and displayed in the UI), and can be used as keys to group instances together, or as part of complex datapoint calculations. The following properties are commonly collected as instance properties:
  • Serial numbers for each FRU discovered in a switch chassis, or drives in a storage system.
  • Metadata for each VM hosted by a Hypervisor (CPU count, memory allocation, virtual NIC count, guest OS, and so on).
  • Port speed for each network interface.

Configuring Active Discovery

Active Discovery is configured for a single DataSource at a time. Therefore, it is configured from the DataSource definition. DataSource definitions control many configurations related to monitoring. For more information, see DataSources Configuration. 

To configure Active Discovery for a DataSource, do the following: 

1. Navigate to My Module Toolbox.
2. Select a DataSource.
3. Select  Edit to expand the Active Discovery options.
4. Toggle the Enable Active Discovery. 
   When enabled, LogicMonitor will automatically find the DataSource’s instances and the resources they apply to. 

Disable Discovered Instances

If the Disable Discovered Instances is toggled on, instances are initially placed in a disabled state upon discovery and automatically moved into the dynamic “Unmonitored” instance group. Monitoring will have to be manually enabled on these instances. For more information, see Instance Groups.

Toggling this option is helpful if you would like to fine tune your instances’ datapoint thresholds prior to enabling monitoring. This ensures you do not receive a flood of unwanted alerts as soon as new instances are discovered.

Automatically Delete Instance

If Automatically Delete Instance option is toggled on, LogicMonitor automatically removes an instance from monitoring if a future Active Discovery iteration reports that it is no longer present on a device.

When automatically removing instances from monitoring, you can choose how long the monitoring history remains in LogicMonitor:

• Delete Immediately—An instance (and all of its monitoring history) is immediately removed from LogicMonitor upon the instance being determined not present.
• Delete After 30 Days—While the instance immediately disappears from the Resources tree upon being determined not present, its monitoring history will remain in LogicMonitor for 30 days before being removed. If the instance is rediscovered within this 30-day window, the prior monitoring history will be re-associated upon rediscovery. This grace period is useful in use cases such as the replacement of a failed network card, where you would want the old history visible once the new card is active.

Discovery Schedule

Active Discovery can be configured to run on a schedule of every 15 minutes, every hour, or once every day. Or, it can be configured to run only when the DataSource is initially applied to a device, or when the Datasource (or the device it applies to) is updated in some way.

Group Method

The Group Method determines how instances are organized upon discovery. 

The are three grouping methods:

• Manual—Manually organize instances into groups after discovery, or leave them permanently ungrouped.
• Regular Expression—This method supports three parameters. 
• Instance level property—An instance group for each unique value of that ILP is automatically created. 

For information, see Instance Groups. 

Collection Arguments

The collection arguments fields change based on the Active Discovery method chosen. 

Discovery Method

The Discovery method field defines the method employed by Active Discovery to find instances. LogicMonitor’s Active Discovery process supports a variety of methods for querying a device or system about the objects it has available for monitoring. These include the following:

• COLLECTOR—Discovers Collectors as instances.
• HTTP—Queries an HTTP/HTTPS URL.
• JDBC—Actuates a database query.
• JMX—Queries a specific Java Management Extensions path.
• PERFMON—Queries a Windows Perfmon class.
• PORT—Connects to specific TCP port(s).
• SCRIPT—Uses the output of a script.
• SNMP—Actuates an SNMP query.
• WMI—Queries a Windows WMI class.
• Various APIs—For some systems and applications, LogicMonitor supports Active Discovery through direct query of proprietary APIs including the Citrix XenServer API, MongoDB API, NetApp API, and VMware ESX API.
• Various public cloud resources—For public cloud resources, LogicMonitor supports Active Discovery through direct query of proprietary cloud systems including those hosted by Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.

For more information on setting the unique arguments required for various discovery methods, see their individual support articles in the product documentation. 

Understanding Active Discovery Filters

Active Discovery filters control what objects are allowed to populate as instances on a device level. These filters are used to preserve the desired alerting and data collection, but prevent alerting on non-critical infrastructure. When filters are in place, every object discovered through the Active Discovery process must satisfy the filter criteria in order to be added into monitoring.

Filters enable you to restrict which instances are added into monitoring through Active Discovery. If one or more filters are in place, instances must match the filter criteria in order to be discovered.

Configuring a Filter

1. Navigate to My Module Toolbox.
2. Select a DataSource.
3. Select the Active Discovery tab and then select  Edit option to expand the Active Discovery options.
4. Scroll down to Filters >   edit.
5. Designate the conditions a particular attribute must meet.

Building a Filter Statement

Several standard operation types such as Equal, NotEqual, LessThan, Contain, and RegexMatch, among others, are available.

Filter Use Cases

Excluding Down Interfaces from Monitoring

To exclude down interfaces, the following filter could be added to a DataSource that monitors interfaces:

Field name	Field information
Property name	auto.interface.operational.state
Operator	Equal
Value	up
Comments	Show interfaces that are up

Assigning Differing Datapoint Threshold to Different Types of Instances

Auto Discovery filters can be used to exclude instances for the purpose of applying different datapoint thresholds to different types of instances. For example, consider you have a Cisco switch with uplink ports that are consistently labeled “Uplink” in their switch port descriptions and edge ports that are not labeled. You are primarily concerned with alerts related to uplink ports, but are still interested in monitoring some aspects of the edge ports.

Accomplishing this requires cloning and modifying various aspects (including the filters) of LogicMonitor’s out-of-the-box Interfaces (64 bit)- DataSource. Ultimately, you end up with three versions of the DataSource: one that applies only to Cisco devices and only monitors uplink ports, one that applies only to Cisco devices and monitors everything that is not an uplink, and one that applies to everything except Cisco devices.

The following set of steps outline the process you need to follow to achieve this use case:

1. Clone the Interfaces DataSource for the purpose of creating a new DataSource that applies only to Cisco uplink ports.
   Give the cloned DataSource a descriptive name. For more information, see Cloning a LogicModule.
2. Update the Applies To field for the cloned DataSource to isCisco() so that it only applies to Cisco devices.
3. Add an Active Discovery filter that restricts instance monitoring to uplink ports.
4. Create a new Datasource that monitors non-uplinks. To do this:
   • Clone the new DataSource you just created.
   • Inverse the filter. For example, use the “NotContain” operator instead of the “Contain” operator.
5. Remove the static thresholds on the Status and StatusFlap datapoints to reduce alerting for non-uplink Cisco gear. For more information, see Tuning Static Thresholds for Datapoints.
6. To prevent the original DataSource from monitoring Cisco interfaces, set Applies To field to hasCategory(“snmp”)&& !isWindows() && !isCisco(). This applies the DataSource to all devices that support SNMP, except Windows devices and Cisco devices).

Filtering Instance-Level Properties

Instance-level properties can be used as filters to determine which instances instances should (and should not) go into monitoring. These properties are created and assigned during Active Discovery.

For example, LogicMonitor’s VMware_vSphere_VMsnapshots DataSource performs Auto Discovery through an embedded Groovy script.

This script assigns a large number of properties to resulting instances, one of these properties being auto.resource_pool, which captures the name of the virtual machine’s resource pool.

For more information, see Resource and Instance Properties.

Troubleshooting SNMP Filtering

It’s possible for an Active Discovery filter to create confusion when you are expecting an instance, but not seeing it. 

A common troubleshooting scenario is when only one NetApp Snapshot volume displays, but more are expected. Using the SNMP OID set on the DataSource definition, you can perform a manual walk to get the full list of volume instances: 

This example shows there is more than one potential instance for discovery. However, the second default filter checks volume size and only puts those into monitoring that do not report a zero size from the OID .1.3.6.1.4.1.789.1.5.4.1.15 and is typically the reason why all expected volume instances are not present.