Using the Collector Debug Facility

You can use the Collector Debug Facility to remotely run debug commands on your Collector. This is helpful for troubleshooting issues with data collection and is typically used on the advice of LogicMonitor support.

In this support article, the following topics are discussed:

Note: The history of Collector debug commands is preserved in the Audit Log.

Accessing the Collector Debug Facility

There are two places from which you can launch the Collector Debug Facility:

  • From a Collector's settings. As shown next, select Settings | Collectors, click the Settings icon for the Collector you would like to debug and, from the Support button's dropdown, select "Run Debug" command.

  • From the Device Tree. Open the DataSource or DataSource instance that you would like to debug and, from the Raw Data tab, click the Debug button.

Debug Command Syntax

The Collector Debug Facility launches in a new browser tab. A list of built-in commands and descriptions display to assist with troubleshooting.

All debug commands should be preceded with a '!'. If you need an example of the syntax for a particular command, enter help !<commandname>, as shown in the following example.

Debug command syntax

The following table highlights some of the most frequently used debug commands. Triangular brackets (i.e. < >) indicate a value that should be replaced. Rectangular brackets (i.e. [ ]) indicate an optional argument that may be included.




!adlist displays a list of the collector's active discovery tasks !adlist
!adetail <taskId> displays detailed information about a specific active discovery task, where taskId can be found with !adlist. Note that the "taskId" reference in the command specification will be labeled as "id" in the output of the !adlist command. !adetail 142
!hostproperty action=add|del host=<hostname> property=<system-property> [value=<property-value>] adds, updates, or removes system properties for a device, where: add is used to add or update the system property and del is used to remove the system property; host is the system.hostname property of the monitored device; property is the system property without the "system." prefix; and value is the new property value

!hostproperty action=del host=localhost property=virtualization

!hostproperty action=add host=localhost property=ips value=,

!tlist [h=<host>] [dsi=<datasourceInstance>] [es=<eventSource>] [c=<collectionMethod>] displays a list of the collector's data collection tasks !tlist c=wmi
!tdetail displays detailed information about a specific data collection task, where taskId can be found with !tlist !tdetail 342
!uptime displays the uptime of the collector !uptime
!restart [collector | watchdog] restarts the specified collector service !restart watchdog
!ping pings the specified host !ping
!logsurf level=all|trace|debug|info|warn|error seq=xxx taskId=xxx [] displays log file entries that are of the specified level. If included, logs will only be displayed for the specified seq and taskId if they are in the specified file, and only n number of logs will be displayed. taskId and seq can be found using the !tlist command, where taskId is the id of a data collection task and seq is the number of times the collector remembers having done the task. !logsurf level=trace ../logs/wrapper.log taskid=833 seq=75
!http [username=username password=password] sends an HTTP request (with username and password, if included) and displays the response !http
!account displays the account information used by sbwinproxy !account
!jdbc [username=username password=password] url=<url> <query> execute a SQL query agains the given device !jdbc url=jdbc:mysql:// username=LogicMonitor password=MyPassword select Name, ID from productDB.Employees


Debug Example: Troubleshooting Data Collection

One of the most common uses of the Collector Debug Facility is troubleshooting data collection for a particular DataSource or DataSource instance. Maybe you just wrote a script DataSource and are getting NaN values, or perhaps one instance out of ten is not reporting data. You can typically use the following steps to identify the issue:

    1. Identify the DataSource or DataSource instance. Find the name of the DataSource in the DataSource definition (this is NOT the same as the display name).

      Example : troubleshooting data collection

  • Use the !tlist command in the Collector Debug Facility of the collector associated with the device the DataSource applies to. You can narrow down the results by using the h=<hostname> and c=<collection type> options.

  • Identify the task for the desired DataSource. You'll see the taskid, followed by an execution count, followed by the collector type, a status, the device name, then the DataSource name, an ival (which is the amount of time it took to execute the task the last time), and finally, a note about the execution.
  • Use the !tdetail command with the taskid as the argument.

  • If you need more information to diagnose the problem, increase the log level for the appropriate collection method of the collector.
  • Wait a polling cycle (or more) and then use the !logsurf command with taskid as an argument and ../logs/wrapper.log as the filename (if you know the latest execution count, you can also limit the results to one operation by including seq=n). You can also include a number argument to limit the results to a certain number of logs. You should see the log entries only for the task whose id is included in the command.

  • If you still haven't identified the issue, contact support.