Collector Debug Facility

Last updated on 02 May, 2024

The Collector Debug Facility is a command-line interface (CLI) that you can use to remotely run debug commands on your Collector. This is helpful for troubleshooting issues with data collection. For example, if you wrote a script DataSource and are getting NaN values, or there is one instance out of ten  not reporting data, you can run the Collector Debug Facility to identify the issue.

Note: The history of Collector debug commands is preserved in the Audit Log. For more information, see Audit Logs Report.

You can run the Collector Debug Facility from the Collector you want to debug, or you can navigate to the DataSource instance in Resources. When you run the Collector Debug Facility, it opens in a new tab and you can run the debug commands applicable to your environment. A list of the debug commands along with their descriptions displays in the Collector Debug Facility interface to assist with troubleshooting prior to entering the commands you need.

Debug Commands for the Collector Debug Facility

The following table lists the debug commands you can run in the Collector Debug Facility for troubleshooting:

!accountDisplays the account information used by sbwinproxy.!account
!adlistDisplays a list of the Collector’s Active Discovery tasks. A taskID is returned for each task.!adlist type=get

!adlist method=ad_snmp
!adetail <taskId>Displays detailed information about a specific Active Discovery task, where taskId can be found with !adlist.

Note: the “taskId” reference in the command specification will be labeled as “id” in the output of the !adlist command.

!adetail 142
!checkcredentialEnables, disables, and checks credential usage on the specified host to determine source of unexpected login action.!checkcrendential proto=snmp user=public

!checkcrendential proto=snmp user=public usage=AP
!hostpropertyAdds, updates, or deletes system properties for a host.hostproperty action=del host=localhost property=virtualization

!hostproperty action=add host=localhost property=ips value=,
!httpSends an HTTP request and displays the response. URL is required.

!http [username=xxx [password=yyy]] [followRedirect=true|false] [method=GET| POST| PUT] [version=1| 1.1] [timeout=<seconds>] url [-h "<header json>"] [-b "<body json>"]

The following are the optional arguments to display the response:

  • username=xxx [password=yyy]
    If your web endpoint requires Basic Authentication, you must include a user if you have a password. However, if you have a user, the password is not required.

  • followRedirect=true|false
    Determines whether or not to follow redirects

  • method=GET| POST| PUT
    Determines HTTP methodversion=1| 1.1
    Determines HTTP version

  • timeout=<seconds>
    Allows you to configure a custom timeout

  • -h “<header json>”
    Allows you to add custom headers

  • -b “<body json>”
    Sends a custom body (usually used with POST

!http method=GET

!http method=POST -h "{"Content-type": "application/json"}" -b "{"key" : "value"}"

!http method=PUT -h "{"Content-type": "application/json"}" -b "{"key" : "value"}"

!jdbcExecutes a SQL query against the specified host.!jdbc ‘url=jdbc:mysql:// username=LogicMonitor password=MyPassword’ select Name, ID from productDB.Employees
!logsurfDisplays log file entries that are of the specified debug 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 !tlist, 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
!opsslLists ciphers and executes s_client using the locally installed OpenSSL binary.
!pingPings the specified host.!ping

!ping type=proxy
!restartRestarts the specified Collector service!restart watchdog

!restart collector
!shealthcheck func=<function> collector=<collector_id>!shealthcheck commands help you determine the health of Collector, memory consumed, and number of scheduled tasks. Based on the result, you can debug the issues and resolve them.

This debug command triggers a healthcheck task for a specific Collector. After you run this command, Santaba schedules a healthcheck task for the specified Collector.
To view the result, you must run !shealthcheck command with function func=detail or func=show.

Typically, you will find a summary of the scheduled task in the result. It also indicates the number of total, finished, and skipped healthcheck tasks. For example, “Latest run has finished. Scheduled checks (total=34, finished=27, skipped=7)”
In case an issue is detected, the issue is summarised in the result. For example, “The disk has a low free space 728.57 MBytes.”
You can run !shealthcheck func=detail collector=<collector_id> debug command to know the details of the issue or get details of the health status of a Collector.

This debug command provides status of all the scripts in detail. For example, “Collector exported jars and executables are not modified.” “The Collector has 177 instances.” 
After you run this command, Collector displays the result fetched by the func=trigger command. For example, for a specific Collector if you run the func=trigger command at 9.00 AM and then run func=detail at 11.00 AM, the Collector health status fetched at 9.00 AM will be displayed.
!shealthcheck func=show collector=123

!shealthcheck func=trigger collector=123

!shealthcheck func=detail collector=123
!tdetail <taskId>Displays detailed information about a specific data collection task, where taskId can be found with !tlist.!tdetail 12323209239991
!tlistLists the Collector’s data collection tasks, including DataSources, ConfigSources, and EventSources. A taskID is returned for each task.

You can narrow the list using the h=<hostname> and c=<collection type> options. 
!tlist c=wmi
!tlist summary=collector
!tlist summary=true lasttime=10 columns=5

Narrow the returned list:
!tlist c=script
!uptimeDisplays the uptime of the Collector.!uptime

In addition, you can enter the following if you need the syntax for a particular command or usage details (for example, optional and mandatory arguments or parameters) and examples, replacing commandname with the applicable command:

help !<commandname>

Requirements for Running the Collector Debug Facility

When running commands using the Collector Debug Facility, the command must be preceded with the following syntax:


Running the Collector Debug Facility

  1. Do one of the following depending on where you want to run the Collector Debug Facility from:
    • To run the Collector Debug Facility from the Collector’s settings, do the following:
      1. Navigate to Settings > Collectors.
      2. Select Manage for the Collector you want to debug from the list of Collectors.
        The Collector’s settings display in a panel.
      3. Select More in the settings panel, and then select “Run Debug Command”.
      4. Select Confirm when prompted.

        The Collector Debug Facility opens in a new tab.
    • To run the Collector Debug Facility from the DataSource in Resources, do the following:
      1. Navigate to Resources > Resources Tree, and select the DataSource or Datasource instance you want to debug.
      2. On the Raw Data tab, select Open Debug Window .

        The Collector Debug Facility opens in a new tab.
  2. Enter the applicable commands in the Collector Debug Facility.
    For example, use the !tlist command to list the Collector’s data collection tasks, including DataSources, ConfigSources, and EventSources.
    For more information, see Debug Commands for the Collector Debug Facility.


  • If you need more information to diagnose the problem, increase the log level for the appropriate collection method of the Collector. For more information, see Collector Logging.
  • Waiting a polling cycle or more can return more information.
  1. Close the window when finished.
In This Article