LogicModule Association

Missing LogicModules

If a device is not getting all the types of data that are expected, then troubleshooting AppliesTo association and Active Discovery may be needed.

How are LogicModules associated with a device?

First, the Auto Properties Subsystem will perform various checks on a device, and assign the system properties, including the category. For example, the categories may be associated by an OID match.

Next, the datasources are applied, usually by a reference to the system.categories property. There are exceptions where part of a system description, an application-specific token or an externally-added category is needed. The isWindows() convenience function or other LMS function can also be used.

Once a datasource is applied, instances are created, either as a single instance datasource, a datasource where the user must create and maintain an instance list, or, most typically, through Active Discovery.


If it appears a device is not fully collecting the expected metrics, there are several steps that can be performed to troubleshoot. 

  • Glance at the datasource list, does it look right for a device of this type? Is anything obvious missing? For example, for a switch you would expect to see CPU metrics, interfaces and host uptime.
  • If datasources appear to be missing, check the applies-to their definition. Either there’s a problem with the datasource or the auto-properties system has not detected the kind of host. In the latter case, see the help page about devices and applications. 
  • If the device’s system information is not present or inaccurate, it means that auto properties did not complete as expected. Check autoproperties.
  • Check basic connectivity. For example, if you are not seeing datasources that collect via SNMP, ensure SNMP is enabled on the device, UDP 161 is open between the device and the collector, and verify the correct community string has been provided in LogicMonitor via the device properties. 
  • Check the Active Discovery results. Find the collector responsible for the device. Manually schedule an active discovery session for the device, and then open the debug commands for the devices collector. Run !adlist to get a list of the active discovery jobs. (it may be helpful to filter on the host using an optional h=<hostname> argument to see only the discovery associated with a given host. The list will have a series of task numbers on the left. Find the number which corresponds with the discovery you’re interested in and copy it.
  • From the collector debug, you can find the discovery task ID and see the results of its attempt to find instances. Run !adetail <taskid> in order to see the details of the AD run you’re interested in. This should show you the host, the host properties, a list of discovered instances, and any possible error messages. Frequently those error message will describe precisely what’s wrong.
  • Attempt to simulate the AD process by looking at the AD type for the datasource. You’ll want to simulate that AD method as best as is possible, and consider testing any filters in the datasource definition that may prevent an expected interface from appearing. For example, the Interfaces datasource by default excludes interfaces that are not connected, or report a status 2.