- About LogicMonitor
- Cloud Monitoring
- Dashboards and Widgets
- Getting Started
- LM Service Insight
- About LogicModules
- Creating & Managing DataSources
- Active Discovery
- Data Collection Methods
- Groovy Support
- PowerShell Support
- Setting Up JobMonitors
- Help & Troubleshooting
- User-Defined AppliesTo Functions
- SNMP sysOID Maps
- Rest API Developers Guide
- RPC API Developers Guide - Deprecated
- Servicenow CMDB Integration
- Terminology and Syntax
Generally, the pre-defined collection methods 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 retrieve performance metrics from hard-to-reach places. A few common use cases for the SCRIPT collection method include:
- Executing an arbitrary program and capturing its output
- Using an 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:
- Write code that retrieves the numeric metrics you’re interested in. If you have text-based monitoring data you might consider a Scripted EventSource.
- Print the metrics to standard output, typically as key-value pairs (e.g. name = value) with one per line.
- Create a datapoint corresponding to each metric, and use a datapoint post-processor to capture the value for each key.
- 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 respectively.
In standard SCRIPT mode, the collection script is run for each of the DataSource instances at each collection interval. Meaning: for a multi-instance DataSource that has discovered five instances, the collection script will be run five 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 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 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
As 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 prefer or you can run a binary directly
In this Article: