Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
Active Discovery is the process by which LogicMonitor determines all of the similar components of a particular type on a given system. The output of an Active Discovery process is one or more instances for which LogicMonitor can collect a particular type of data.
Instances are organized under their parent DataSources in the Resources tree.
Active Discovery is extremely valuable for ensuring that monitoring remains up to date with changes in your environment. For example, Active Discovery ensures that each new VM created on your virtualization stack is discovered and monitored, or that each new volume added to your storage system is discovered and monitored. Without Active Discovery, you would have to remember to manually update your monitoring instances every time you make a change to your production environment.
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 (as discussed in the Configuring Active Discovery section of this support article) and varies per DataSource. For example, objects that typically change less frequently (e.g. the number of fans or CPUs in a system) are assigned discovery schedules of once a day by LogicMonitor. Objects that are likely to change more frequently (e.g. volumes on a NetApp disk array), however, are assigned discovery schedule of several times per hour.
In addition to executing according to the schedule defined in the DataSource definition, Auto Discovery additionally runs when:
Note: When you disable DataSource monitoring for a particular resource or group of resources (as discussed in Disabling Monitoring for a DataSource or Instance), Active Discovery is also disabled for that DataSource. This means that instances will not be discovered, updated, or deleted for those impacted resources.
Active Discovery retrieves the following information for each instance it finds:
Note: Instance property collection is available only with Active Discovery processes that use script, SNMP, or WMI query methods.
Note: In addition to gathering instance properties via Active Discovery, you can also manually assign properties to instances, as discussed in Resource and Instance Properties.
Active Discovery is configured on a per-DataSource basis. Therefore, it is configured from the DataSource definition. DataSource definitions control many configurations related to monitoring and are discussed in detail in Creating a DataSource.
To configure Active Discovery for a DataSource, navigate to Settings | LogicModules | DataSources and open the DataSource. Scroll down to (and expand) the Active Discovery heading to display all available Active Discovery settings. Each is discussed next.
Note: A DataSource must be multi instance (i.e. its Multi-instance option must be checked under the General Information heading) in order for Active Discovery to be configured.
Check the Enable Active Discovery option to enable Active Discovery. When enabled, LogicMonitor will automatically find a DataSource’s instances on the devices that the DataSource applies to.
If the Disable Discovered Instances option is checked, instances are initially placed in a disabled state upon discovery and automatically moved into the dynamic “Unmonitored” instance group (see Instance Groups for more information on instance groups). Monitoring will have to be manually enabled on these instances.
Checking 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.
If the Automatically Delete Instance option is checked, LogicMonitor will automatically remove an instance from monitoring if a future Active Discovery iteration reports that it is no longer present on a device.
As a best practice, uncheck this option if you would like to receive alerts for instances even if they are not present. For example, you would likely not want this option checked if Active Discovery detects that a service should be monitored by finding a listening TCP port. This is because, if the service were to fail, the port would stop responding, Active Discovery would report the instance as no longer present, it would be removed from monitoring, and you would no longer receive alerts for it—at precisely the time you would want to receive alerts for it.
When automatically removing instances from monitoring, you can choose how long the monitoring history will remain in LogicMonitor:
As discussed in the Active Discovery Execution section of this support article, Active Discovery can be configured to execute on a schedule of every 15 minutes, every hour, or once every day. Or, it can be configured to execute 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.
The Discovery method field defines the method (SNMP, WMI, script, etc.) 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 options available under the “Parameters” heading dynamically update depending upon the discovery method chosen. For more information on setting the unique parameters required for the various discovery methods, see their individual support articles.
Filters allow you to restrict which instances are added into monitoring via Active Discovery. If one or more filters are in place, instances must match the filter criteria in order to be discovered.
To create a filter, click the plus sign (+) icon and designate the conditions a particular attribute must meet. Attributes can represent instance-level properties, SNMP OIDs, or attributes found in WMI query outputs.
Note: When building filter statements, several standard operation types such as Equal, NotEqual, LessThan, Contain, and RegexMatch (to name a few) are available. Although most of these are self explanatory, one common point of confusion we see is the use of Contain to filter for values such as “A|B” where the assumption is that instances with A or B in the string will be discovered. However, because values paired with the Contain operation are searched as a single string (“A|B” must literally be present), a RegexMatch operation should be used when OR statements are desired.
Equal
NotEqual
LessThan
Contain
RegexMatch
See the Understanding Active Discovery Filters section of this support article for several real-world use case scenarios for Active Discovery filters.
The Group Method field determines how instances will be organized upon discovery. You can choose “Manual” as the group method to manually organize instances into groups after discovery (or leave them permanently ungrouped), or you can choose one of the auto grouping methods available from the dropdown. For detailed information on automating the management of instance groups, see Instance Groups.
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 via the Active Discovery process must satisfy the filter criteria in order to be added into monitoring.
Note: Multiple filter lines are joined using the logical AND operator; a discovered instance must satisfy the criteria of ALL filters in order to be added into monitoring.
In the following sections, we’ve highlighted several common use cases for Active Discovery filters.
Often, our customers are not interested in monitoring down interfaces. So, to exclude down interfaces, the following filter could be added to a DataSource that monitors interfaces.
When walking the table of interfaces via SNMP, each discovered interface has the interface status OID queried. When this filter is in place, that status must be a “1” in order for the interface to meet the filter criteria and get added into monitoring. If the interface is down or in testing, it will not be added into monitoring and thus won’t clutter the Resources tree with inactive interfaces. And, because Active Discovery runs periodically, if the interface is brought up later, it will pass the filter and go into monitoring.
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’re 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’ll 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:
This filter assumes the presence of “Uplink” in the interface description (OID 1.3.6.1.2.1.31.1.1.1.18), but there are many other ways to accomplish this same restriction.
It is a common practice to reconfigure existing non Active Discovery DataSources to have them apply automatically to multiple devices. The Microsoft_Windows_Services DataSource is often cloned and edited for enabling Active Discovery to filter and monitor selected Windows services. For example, filtering can be used to monitor all services that contain “Windows” in their names and that are set to automatically start.
Consider the output of the WMI query used for this class, shown below. It represents the beginning of a very long list of services, obtained from a test device, by calling the win32_service class.
$ !wmi h=10.37.13.177 select * from win32_service >>>>>>> SYSTEMCREATIONCLASSNAME=>Win32_ComputerSystem STATE=>Stopped STATUS=>OK DESCRIPTION=>Adobe Acrobat Updater keeps your Adobe software up to date. STARTED=>false STARTMODE=>Disabled ACCEPTSTOP=>false DISPLAYNAME=>Adobe Acrobat Update Service DESKTOPINTERACT=>false TAGID=>0 EXITCODE=>1077 CREATIONCLASSNAME=>Win32_Service NAME=>AdobeARMservice WAITHINT=>0 STARTNAME=>LocalSystem PATHNAME=>"C:\Program Files (x86)\Common Files\Adobe\ARM\1.0\armsvc.exe" INSTALLDATE=> CHECKPOINT=>0 SERVICESPECIFICEXITCODE=>0 ACCEPTPAUSE=>false CAPTION=>Adobe Acrobat Update Service PROCESSID=>0 SYSTEMNAME=>WIN-DOES SERVICETYPE=>Own Process ERRORCONTROL=>
Because all services will display the same class attributes regardless of actual value, these attributes can be used in a filter to monitor only those services that are relevant.
The DISPLAYNAME and STARTMODE attributes are used here to put all services (i.e. instances) into monitoring that both contain “Windows” in their names and are set to automatically start.
Instance-level properties can also 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 out-of-the-box VMware_vSphere_VMsnapshots DataSource performs Auto Discovery via an embedded Groovy script. As shown next, 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.
If you wanted to exclude instances from certain pools (e.g. lab or test environment pools that don’t require alerting), you could create a filter based on this instance property.
This filter excludes virtual machines from any resource pools named “LAB”.
For more information on instance-level properties, see Resource and Instance Properties.
Sometimes, an Active Discovery filter can create confusion to a customer expecting an instance, but not seeing it. For example, our out-of-the-box NetAppSnapVol- DataSource features the default filters shown next.
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, as shown next.
$ !snmpwalk SOMEHOST .1.3.6.1.4.1.789.1.5.4.1.2 Walking OID .1.3.6.1.4.1.789.1.5.4.1.2 from host=SOMEHOST, version=v2c, port=161, timeout=3 seconds: 1 => aggr2 10 => /vol/cache1img3/.snapshot 11 => /vol/cache1img4/ 12 => /vol/cache1img4/.snapshot 13 => /vol/cache1img5/ 14 => /vol/cache1img5/.snapshot 15 => /vol/cache1img6/ 16 => /vol/cache1img6/.snapshot 17 => /vol/cache1img7/ 18 => /vol/cache1img7/.snapshot 19 => /vol/cache1img8/ 2 => aggr2/.snapshot 20 => /vol/cache1img8/.snapshot 21 => /vol/cachepreprod/ 22 => /vol/cachepreprod/.snapshot 23 => /vol/cache1imgtest/ 24 => /vol/cache1imgtest/.snapshot 3 => /vol/new_root/ 4 => /vol/new_root/.snapshot 5 => /vol/cache1img1/ 6 => /vol/cache1img1/.snapshot 7 => /vol/cache1img2/ 8 => /vol/cache1img2/.snapshot 9 => /vol/cache1img3/
Here there are indeed more than one potential instances 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.
In This Article
