Scripted Data Collection Overview

Generally, the pre-defined collection mechanisms such as SNMP, WMI, WEBPAGE, etc. are sufficient for extending LogicMonitor with your own custom datasources. However, in some cases you may need to use the SCRIPT mechanism to get pesky performance metrics from hard-to-reach places. A few common use cases for the SCRIPT collection mechanism include:

  • executing an arbitrary program and capturing it output
  • using a HTTP API that requires session-based authentication prior to polling
  • aggregating data from multiple SNMP nodes or WMI classes into a single datasource
  • measuring the execution time or exit code of a process

Script Collection Approach

Creating custom monitoring via a script is straightforward. Here’s a high-level overview of how it works:

  1. Write some code that retrieves the numeric metrics you’re interested in. If you have text-based monitoring data you might consider a Scripted Eventsource.
  2. Print the metrics to standard output, typically as key-value pairs (e.g. name = value) with one per line.
  3. Create a datapoint corresponding to each metric, and use a datapoint post-processor to capture the value for each key.
  4. Set alert thresholds and/or generate graphs based on the datapoints.

Script Collection Modes

Script-based data collection can operate in either an “atomic” or “aggregate” mode. We refer to these modes as the collection types SCRIPT and BATCHSCRIPT.

In standard SCRIPT mode, the collection script is run for each of the datasource instances at each collection interval. Meaning: in a multi-instance datasource that has discovered 5 instances, the collection script will be run 5 times at every collection interval. Each of these data collection “tasks” is independent from one another. So the collection script would provide output along the lines of:

key1: value1
key2: value2
key3: value3

And then three datapoints would need be created: one to for each key-value pair.

With BATCHSCRIPT mode, the collection script is run only once per collection interval -- regardless of how many instances have been discovered. This is much more efficient, especially when you have many instances from which you need to collect data. In this case, the collection script needs to provide output that looks like:

instance1.key1: value1
instance1.key2: value2
instance1.key3: value3
instance2.key1: value1
instance2.key2: value2
instance2.key3: value3

Just like with SCRIPT collection, three datapoints would need be created to collect the output values.

Script Collection Types

LogicMonitor offers support for three types of script-based datasources: embedded groovy, embedded powershell, and external. Each type has advantages and disadvantages depending on your environment:

  • Embedded Groovy Scripting: cross-platform compatibility across all collectors, with access to a broad number of external classes for extended functionality
  • Embedded PowerShell Scripting: available only on Windows collectors, but allows for collection from systems that expose data via PowerShell cmdlets
  • External Scripting: typically limited to a particular Collector OS, but the external script can be written in whichever language you like  or you can run a binary directly