SL1 Development Pre-Requisites
This document will introduce you to key tools and concepts that you should understand prior to using the Snippet Framework.
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.
Discovery and Credentials
Discovery is a process that automatically finds all hardware-based, logical devices and their associated components, including software applications in your network. For each device, hardware component, or software application the discovery process finds, the discovery process can collect a list of open ports, DNS information, SSL certificates, list of network interfaces, device classes to align with the device, topology information, and basic SNMP information.
Credentials are access profiles, generally a username and password, that allow SL1 to retrieve information from remote software applications and devices.
Credentials are located here:
Manage > Credentials
For more information regarding Credential usages, see: Managing Credentials.
For more information on setting up Discovery, see: What is Discovery?
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.
For a deeper look into how Dynamic Application processing pipelines work, see: Modernizing the Dynamic Application Processing Pipelines.
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.
Snippets
Snippets are reusable Python code blocks that provide the logic for the collection and manipulation of data. A Snippet Dynamic Application performs collection by executing Snippets. SL1 passes credentials and other configuration information to the snippet, and at the end of execution, the snippet must pass collected data back to SL1.
For more information on Snippet implementation, see: Introduction to Snippet Dynamic Applications.
For example of how a Snippet is used and configured, see: Example - A Random Number Generator Dynamic Application.
Snippet Arguments
The Snippet Argument is an identifier that allows a snippet to return data for a given collection object. This text field allows the user to specify all attributes for information collection and helps the Snippet Framework developer to solve most collection problems without any traditional programming.
Snippet arguments allow the customization of
The protocol used for device communication.
The resource from which to request the data.
The transformations to apply to the response received.
For most collections, the snippet argument will suffice and will be modular enough to collect any required information. In special cases, these built-in steps will not be sufficient. In such cases, the Snippet Framework allows for Snippet Functions to be used or written to customize the collection even further as it moves through the step.
You can find snippet arguments under:
System > Manage > Dynamic Applications > Wrench icon on specific Dynamic Application > Collections Tab
These details are covered further in the documentation in the Snippet Framework.
Libraries and Execution Environments
A ScienceLogic Library consists of metadata and Python files that can be used by the Dynamic Applications, credential tests, and Run Book Actions that use snippets.
An Execution Environment is an on-demand Python Virtual Environment that includes the supporting modules, code, scripts, directories, and files (packaged in one or more ScienceLogic Libraries) needed to run a snippet. An Execution Environment includes its own installation directories, does not share libraries with other environments, and allows granular control of dependencies and versions.
You can find the Libraries Manager under:
System > Customize > ScienceLogic Libraries
You can edit Execution Environments using the Actions Button on the Libraries Manager Page mentioned above.
You can align one or more ScienceLogic Libraries to an execution environment. You can align only one Execution Environment to a Dynamic Application at a given time.
You must specify an Execution Environment when creating or editing the following:
Snippet or Internal Collection Dynamic Applications
Credential tests
Run Book Action policies that execute a snippet
For more information on ScienceLogic Libraries, see: What is a ScienceLogic Library?
For an introduction to Execution Environments, see: What is an Execution Environment?
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?
Dynamic Single and UI Debug
As a Dynamic Application developer, you can test and debug your Dynamic Applications using the SL1 user interface or the command line. In the SL1 user interface, the UI Debug feature lets you run your Dynamic Application against a remote device on a collector unit (CU) and view the output. The dynamic_single.py script performs the same function directly at the command line of a CU.
You can find the UI Debug under:
Devices > Select Desired Device > Collections Tab > Click the ellipses ... > Run Now
For a tutorial on executing a single Dynamic Application, see: How to Run a Single Dynamic Application in DEBUG Mode.
PowerPacks
A PowerPack is an exportable and importable package of assets that can contain Dynamic Applications, device classes, device templates, event policies, and many other preconfigured elements. A PowerPack is a way you can move content between SL1 systems in an easy-to-manage package.
PowerPacks can be managed here:
System > Manage > PowerPacks
You can create, import, or install PowerPacks from the Actions button on the PowerPacks page.
For more information about PowerPacks, see: What is a PowerPack?
For instructions on building a PowerPack, see: Creating a PowerPack.