Glossary

Cacher

A Cacher is a step-type that caches the current result. Before collection, a cacher has the ability to fast-forward through previous steps if the data is already present.

Collections

Collection is a process that retrieves Dynamic Application-based information from a device. After discovering a device, you can define monitoring policies for that device in SL1. Unlike discovery, collection tasks run at scheduled intervals throughout the day.

A collection contains all pertinent information regarding a specific Dynamic Application Collection Object. To learn more about Collection, review the Collection documentation.

For more information about collections, see What is Collection?

For an in-depth look at using Collection Objects, see How Does a Collection Object Work?

Devices

SL1 can monitor any device on your network, even if your organization uses a geographically diverse network. For each managed device, you can monitor status, create policies, define thresholds, and receive notifications. In SL1, devices also include component devices and virtual devices.

For more information on specific device types and usages, see Introduction to Devices.

Dynamic Applications

Dynamic Applications are the customizable instructions that tell SL1 what data to collect from devices and applications. SL1 includes Dynamic Applications for the most common hardware and software. You can customize these default Dynamic Applications to suit your specific needs.

You can find Dynamic Applications under:

System > Manage > Dynamic Applications

For more information on specific Dynamic Application types and usage, see: What is a Dynamic Application?

For more information on creating a Dynamic Application, see: Creating a Dynamic Application.

Dynamic Component Mapping (DCM)

Dynamic Component Mapping allows SL1 to collect data from a single management system. Using this data, SL1 can create multiple device records for the entities managed by that single management system.

SL1 uses Dynamic Applications to retrieve data from the management system and discover each entity managed by that management device. SL1 then uses that retrieved data to create a device for each managed entity. In some cases, the managed entities are nested.

A managed entity is called a component device. A component device is an entity that runs under the control of a management system.
The root device is a device that manages one or more component devices.
A parent device is a device that has associated entities modeled as component devices. A parent device can be either a root device or another component device.
A component identifier is a collection object that SL1 uses to collect and populate information about a component device, such as the device name.

Execution Plan

A list of steps that inform the Snippet Framework how to gather and transform the data which will be consumed by SL1.

Processor

A Processor is a step-type that performs an operation on data from the previous step.

Request ID

The unique representation for the step that is used during de-duplication which increases the performance of the Snippet Framework. Likewise, if the uniqueness is not properly identified, non-unique requests may be grouped together.

Request More Data

Request More Data is a step-type that enables the Snippet Framework to perform a looping operation to collect additional data. For example, pagination would require a Request More Data step.

Requestor

A Requestor is a step-type that performs an IO operation to gather raw data.

Snippet

Python code defined within a SL1 Dynamic Application.

Snippet Arguments

A Snippet Argument is the interface between a user and the Snippet Framework and entered within the Dynamic Application Collections page. This text is processed by the Syntax that converts the text into an Execution Plan which then informs the Snippet Framework to execute the steps in the correct order.

Snippet Framework

The Snippet Framework enables the low-code / no-code collection of data to be consumed by SL1.

Step

A re-usable piece of code that performs a single function which is executed by the Snippet Framework. Steps are chained together to create an execution plan for the Snippet Framework.

Step Path

A list of unique Request IDs that define uniqueness that is used during de-duplication.

Substitution

Substitution enables a Snippet Argument to use context-aware information to create a targeted argument. For example, if you need to make a call using the device_id you would be able to specify $did within the argument and the Snippet Framework would automatically replace the text with the value.

Syntax

A Syntax is a step-type that converts the Snippet Argument into something the Snippet Framework can consume to perform the collection.

There are currently 2 YAML-based Syntaxes built-in to the Snippet Framework: the standard low_code Syntax and the Prometheus specific promql Syntax. When utilizing any Syntax, the Snippet Argument must begin with the name of the Syntax, followed by a colon (:), i.e. <syntax_name>:<snippet_argument_content>. When using the low_code Syntax, the Snippet Argument would look like this:

low_code:  # Syntax name followed by colon delimiter
  version: 2  # Snippet argument content