LogicModule changes (including New, Updated, and Deprecated LogicModules) are announced for each LogicMonitor release. See Platform Release Notes.

This table tracks the LogicModules that have been deprecated. If a replacement is available, we will provide it before we officially remove the deprecated LogicModules in a future release.

2025

2024

2023

2022

2021

Importing LogicModule replacements

When importing a replacement LogicModule, you will not experience any immediate data loss due to the name variation that LogicMonitor expressly adds. However, there will be a diversion in data collection between the deprecated and new LogicModule, and you will potentially collect duplicate data and receive duplicate alerts for as long as both LogicModules are active.

For this reason, we recommend that you disable monitoring of the DataSource instances at the resource or resource group level after you have imported its replacement. When DataSource monitoring is disabled in this way, it stops querying the host and generating alerts, but maintains all historical data.

At some point in time, you may want to delete the legacy DataSource altogether, but consider this move carefully as all historical data will be lost upon deletion. For more information on disabling DataSource monitoring, see Disabling Monitoring for a DataSource or Instance.

When defining alert messages or integrating alert data with external systems (e.g., ticketing or chat systems), tokens are available to customize the message or integration delivery to the current condition. These tokens are substituted at the time of generation so that the alert or integration delivery can include dynamic information.

The following article lists currently supported tokens and any available substitutions.

Token Types

• Collector Down and Failover Tokens—Can be used in alert messages notifying you of a Collector down and failover to a backup Collector, if configured.
• DataSource Tokens—Can be used in alert messages that originate from a datapoint defined by a DataSource.
• Root Cause Analysis Tokens—Can be used in alert messages that undergo root cause analysis.
• Website Tokens—Can be used in alert messages that originate from a monitored website.
• JobMonitor Tokens—Can be used in alert messages that originate from a JobMonitor definition.
• Cluster Alert Tokens—Can be used in alert messages that originate from a cluster alert (i.e., an alert that is triggered based on the status of a datapoint across multiple resources in a resource group).
• EventSource Tokens—Can be used in alert messages that originate from an EventSource definition. The following types of EventSources have additional tokens available:
  • Windows Event Log Tokens
  • IPMI Event Tokens
  • SNMP Trap Tokens
  • Syslog Event Tokens
• LM Integration Tokens—Can be used when integrating alert data with external systems, such as message tools or ITSM solutions.

Available Tokens

The following table lists the available alert message tokens, organized by LogicModule or function:

You may want to clone a LogicModule when:

• you are creating a LogicModule with similar functionality to an existing LogicModule, and you don’t want to start from scratch
• you plan on making major changes to an existing LogicModule, and you’d like to have a backup copy in case something goes wrong
• you want to apply a slightly different version of the LogicModule to a subset of your devices

To clone a LogicModule, find the LogicModule definition from Settings | LogicModules | LogicModules and select clone in the lower right hand corner. In the following example, we show the process of cloning a DataSource:

The cloned LogicModule will be an exact copy of the original – including all graphs and overview graphs. You’ll need to give it a name and define which devices the LogicModule should apply to (by default, the Applies To field is commented out when you clone a LogicModule, so it won’t apply to any resources). You can then change the new LogicModule in any way you want – adding in different filters, or different datapoints or graphs, and so on.

Note: Cloning LogicModules with passwords will not replicate the password. You will have to manually set a password for the cloned LogicModule.

LogicMonitor continuously adds, updates, and improves LogicModules. New version of LogicModules are not automatically pushed out to customer accounts. There is risk of certain LogicModule updates removing historical data. For more information, see “Risks to Updating”.

Risks to Updating

The following table explains the potential risks when updating LogicModules:

Importing LogicModules

1. Click Settings.
2. From the list of LogicModules, click the type you want to import.
3. Click Add > From LogicMonitor Repository.
4. Click OK.

The following dialog displays:

5. Select the LogicModule you want to import. Keep in mind the following for each status:

• “New”: This may result in new monitoring and additional alerts.
• “Updated – in use” or “Updated – not in use”: You can view the difference between the updated LogicModule and the one installed on your account using a Diff file similar to the following:

6. (Optional) From the Diff file page, you can open your existing LogicModule in a new window and manually update it with the changes highlighted in the Diff file.
7. Select the LogicModules you want to import, and click Save.

A success message displays after the LogicModules are imported.

LogicModules are templates that define how LogicMonitor should access, collect, alert on, and configure data coming from Resources that you monitor. LogicModule definitions can be viewed, edited, and created from the Settings > LogicModules. There are 8 types of LogicModules.

DataSources

DataSources define what numeric time-series data should be collected, how it should be collected, and what values should be graphed and trigger alerts. LogicMonitor comes with over a thousand pre-configured DataSources to allow you to instantly begin monitoring the devices in your infrastructure, with new DataSources added with each release.

For more information, see our Creating DataSources.

EventSources

EventSources define monitoring and alerting activity for non-numeric event-based data, such as IPMI event log events, SNMP traps, Windows event logs, and Syslog events. There are two types of EventSources:

1. EventSources that monitor asynchronous event messages received by the Collector
2. EventSources that actively monitor event logs or log files for the presence of specific events

For more information, About EventSources.

ConfigSources

ConfigSources use embedded Groovy or PowerShell scripts to access, collect, and alert on changes to your Resources’ configuration files. For more information, see Creating ConfigSources.

PropertySources

PropertySources provide a means of programmatically configuring device properties using an embedded Groovy or PowerShell script. Arbitrary properties and values can be assigned to devices using PropertySources. Automated property assignments can be used for such purposes as inventory tracking and reporting, troubleshooting, and dynamic grouping.

For more information, see Creating Property Sources.

TopologySources

TopologySources enable LogicMonitor’s topology mapping capabilities. Pre-built by LogicMonitor, TopologySources leverage layer 2 discovery protocols (such as LLDP and CDP) to gather information that is used to define logical relationships among the many monitored devices in your network.

For more information on how TopologySources facilitate topology mapping, see TopologySource Overview and Topology Mapping Overview.

JobMonitors

JobMonitors monitor batch jobs on Windows and Linux/Unix systems to ensure jobs start on time, complete when expected, and exit with the proper exit code. Job monitoring is enabled using a supplied wrapper script to run the batch job. The wrapper script sends information to the Collector about the job execution.

For more information, see JobMonitor LogicModules.

AppliesTo Functions

AppliesTo Functions are used to apply LogicModules to devices, specify criteria for membership in dynamic groups, configure dashboard widgets, and perform other various functions across the LogicMonitor platform.

For more information, see AppliesTo Functions.

SNMP SysOID Maps

SNMP SysOID Maps are used to classify devices that respond to SNMP. A SysOID Map consists of two parts: a full or partial sysOID, formatted as a regular expression, and one or more categories associated with that sysOID. When a device responding to SNMP is added for monitoring, its SysOID is checked against the entries in the SNMP SysOID Maps. When a match is found, the corresponding categories are added to the system.categories property of the device.

For more information, see SNMP SysOID Maps.

Module Snippets

Module snippets are pieces of reusable code that can contain functions, classes, and data. Snippets are used by newer LogicModules to implement common functionality, such as formatting data for the Collector and generating topologies, as well as implement other device-specific code, such as interacting with APIs.

Snippets are cached locally on the collector in the LogicMonitor installation directory under /lib/snippets on Linux or \lib\snippets on Windows. All snippet versions are maintained within this directory.

Collectors automatically check for snippet updates at least once a day or when a requested snippet is not present locally. If you want to turn off automatic snippet updates for a collector, you may do so by adding snippet.auto.update=false to the agent.conf file for a given collector. This is not recommended as it prevents security updates and bug fixes for modules using snippets.