Troubleshooting script code run by the LogicMonitor Collector can be a bit tricky. We've provided a few tricks to make this process easier.
Scripting Best Practices
LogicMonitor's scripting features provide for powerful extensibility of your monitoring, but as they say: with great power comes great responsibility. To ensure your scripts run trouble-free be aware that:
- Because LogicMonitor scripts are run by your Collector, they're limited by the overall horsepower in that system. As such, they should be designed to be as lightweight as possible.
- Datasource collection scripts which are run once per poll should complete within 1m to ensure data can be processed within the polling interval.
- When developing new script-based monitoring, you may want to install a new Collector to use as a sandbox environment. This will ensure your script development has no chance of interfering with production operations.
Developing Scripts with the Collector Debug Facility
Before installing your monitoring script into the appropriate LogicModule, you'll first want to test it out to make sure it's behaving as designed. For an External Script this is straightforward, as you'll typically develop and test directly on a Collector host by directly calling the appropriate interpreter for your script language.
For Embedded Groovy or Embedded PowerShell scripts, you can develop and test your scripts directly within LogicMonitor using the Collector Debug facility. Although you can do so with our built-in tools, we strongly recommend augmenting these by installing the LogicMonitor Script Debug Helper extension for the Google Chrome browser. Either way, you can author and debug your Groovy and PowerShell scripts on-the-fly using the !groovy and !posh debug commands.
Either of these commands will launch a textarea in which you can write script code, iteratively test your code by submitting it to the Collector's Groovy/PowerShell script interpreter, and then view its output.
Once your code does what you want it to do e.g. generate DataSource active discovery records or key/value pairs, EventSource JSON, ConfigSource configs, or some other meaningful output you can copy it into the appropriate LogicModule.
Note that when using the Collector Debug scripting facility, you'll need to hard-code any variables based on device properties. For example if you mean for a script to dynamically get the hostname against which it should run, you'd use
hostname = hostProps.get("system.hostname");
in Groovy or
$hostname = "##system.hostname##";
in PowerShell. When running this code in the Collector Debug system you'll need to hard-code these variables to match the device against which you're developing.
Diagnosing Scripts with Output Logging
Once a script has been applied to a particular LogicModule, it is run by the Collector as part of its device polling & monitoring activities. This makes its operation somewhat opaque, which is challenging when you want to know why a script isn't behaving as expected.
To make script operations more transparent, you'll need to enable debug logging on the Collector. Upon doing so the Collector will enable the writing of script output and errors to individual files in the Collector logs directory. Meaning: every time a script component is run by the Collector, both the STDOUT and STDERR from those processes are written to individual files. To prevent filling the Collector with debug files, each subsequent run of a Collector script overwrites the previous generation of the output and error files.
- Linux: /usr/local/logicmonitor/agent/logs
- Windows: C:\Program Files (x86)\LogicMonitor\Agent\logs
When you've completed debugging, we recommend disabling script output logging by returning the collector log setting for collector.script=info.