- About LogicMonitor
- Cloud Monitoring
- Collector Overview
- Collector Installation
- Collector Management
- Collector Failover
- Collector Configurations
- Collector Troubleshooting
- Collector Groups
- Dashboards and Widgets
- Getting Started
- LM Logs
- LM Service Insight
- Rest API Developers Guide
- RPC API Developers Guide - Deprecated
- Servicenow CMDB Integration
- Terminology and Syntax
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.
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 debug commands and their descriptions display to assist with troubleshooting.
All debug commands should be preceded with a ‘!’. If you need syntax for a particular command, enter help !<commandname>, as shown next.
The following table highlights some of the most frequently used debug commands. For usage details (e.g. optional and mandatory arguments, parameters, etc.) and examples, enter the help !<commandname> from the Collector Debug Facility.
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:
- 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).
- 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, as discussed in Collector Logging.
- 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.
In this Article: