.. include:: ../external_links.txt .. _sl1-dev-prereq: ############################## SL1 Development Pre-Requisites ############################## This document will introduce you to key tools and concepts that you should understand prior to using the |FRAMEWORK_NAME|. * :ref:`Devices ` * :ref:`Discovery and Credentials` * :ref:`Dynamic Applications ` * :ref:`Dynamic Component Mapping (DCM) ` * :ref:`Snippets ` * :ref:`Snippet Arguments ` * :ref:`Libraries and Execution Environments ` * :ref:`Collections ` * :ref:`Dynamic Single and UI Debug ` * :ref:`PowerPacks ` ******** .. _devices_preq: ******* 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`_. .. image:: ../documents/_static/NewUIDevices.png ******** .. _discovery_credentials_preq: ************************* 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: .. code-block:: none Manage > Credentials For more information regarding Credential usages, see: `Managing Credentials`_. For more information on setting up Discovery, see: `What is Discovery?`_ ******** .. _dynamic_applications_preq: ******************** 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: .. code-block:: none 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`_. .. image:: ../documents/_static/DynamicApplications.png ******** .. _dynamic_component_mapping_preq: ******************************* 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_preq: ******** 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`_. .. image:: ../documents/_static/DefaultSnippet.png ******** .. _Snippet_Arg: ***************** Snippet Arguments ***************** The :ref:`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 |FRAMEWORK_NAME| 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 |STEP_NAME_PLURAL| will not be sufficient. In such cases, the |FRAMEWORK_NAME| allows for :ref:`Snippet Functions ` to be used or written to customize the collection even further as it moves through the |STEP_NAME|. You can find snippet arguments under: .. code-block:: none System > Manage > Dynamic Applications > Wrench icon on specific Dynamic Application > Collections Tab These details are covered further in the documentation in the :ref:`Snippet Framework `. .. image:: ../documents/_static/SnippetArgExample.png ******** .. _lib_exe_env: ************************************ 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: .. code-block:: none System > Customize > ScienceLogic Libraries You can edit Execution Environments using the **Actions** Button on the Libraries Manager Page mentioned above. .. image:: ../documents/_static/ExecutionEnvironments.png 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_preq: *********** 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_ui_debug_preq: *************************** 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: .. code-block:: none Devices > Select Desired Device > Collections Tab > Click the ellipses ... > Run Now .. image:: ../documents/_static/UIDebug.png For a tutorial on executing a single Dynamic Application, see: `How to Run a Single Dynamic Application in DEBUG Mode`_. ******** .. _powerpacks_preq: ********** 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: .. code-block:: none System > Manage > PowerPacks You can create, import, or install PowerPacks from the **Actions** button on the PowerPacks page. .. image:: ../documents/_static/PowerPackPage.png For more information about PowerPacks, see: `What is a PowerPack?`_ For instructions on building a PowerPack, see: `Creating a PowerPack`_.