.. include:: ../external_links.txt .. include:: ../common.txt ******** Glossary ******** .. _glossary_cacher: Cacher ====== A Cacher is a :ref:`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 |PRODUCT_NAME|. 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. .. image:: ../_static/da_collections_page.png 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 ======= |PRODUCT_NAME| 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 |PRODUCT_NAME|, devices also include `component devices`_ and `virtual devices`_. For more information on specific device types and usages, see `Introduction to Devices`_. .. image:: ../_static/NewUIDevices.png Dynamic Applications ==================== **Dynamic Applications** are the customizable instructions that tell |PRODUCT_NAME| what data to collect from devices and applications. |PRODUCT_NAME| 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`_. .. image:: ../_static/DynamicApplications.png Dynamic Component Mapping (DCM) =============================== Dynamic Component Mapping allows |PRODUCT_NAME| to collect data from a single management system. Using this data, |PRODUCT_NAME| can create multiple device records for the entities managed by that single management system. |PRODUCT_NAME| uses Dynamic Applications to retrieve data from the management system and discover each entity managed by that management device. |PRODUCT_NAME| 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 |PRODUCT_NAME| uses to collect and populate information about a component device, such as the device name. .. _glossary_exec_plan: Execution Plan ============== A list of :ref:`steps ` that inform the :ref:`Snippet Framework ` how to gather and transform the data which will be consumed by |PRODUCT_NAME|. Processor ========= A Processor is a :ref:`step-type ` that performs an operation on data from the previous step. .. _glossary_req_id: 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 :ref:`step-type ` that enables the :ref:`Snippet Framework ` to perform a looping operation to collect additional data. For example, pagination would require a Request More Data :ref:`step `. Requestor ========= A Requestor is a :ref:`step-type ` that performs an IO operation to gather raw data. Snippet ======= Python code defined within a |PRODUCT_NAME| Dynamic Application. .. _glossary_snip_arg: Snippet Arguments ================= A Snippet Argument is the interface between a user and the :ref:`Snippet Framework ` and entered within the Dynamic Application Collections page. This text is processed by the :ref:`Syntax ` that converts the text into an :ref:`Execution Plan ` which then informs the Snippet Framework to execute the :ref:`steps ` in the correct order. .. image:: ../_static/snippet_arguments.png .. _glossary_sf: Snippet Framework ================= The Snippet Framework enables the low-code / no-code collection of data to be consumed by |PRODUCT_NAME|. .. _glossary_step: Step ==== A re-usable piece of code that performs a single function which is executed by the :ref:`Snippet Framework `. Steps are chained together to create an execution plan for the :ref:`Snippet Framework `. .. _glossary_step_path: Step Path ========= A list of unique :ref:`Request IDs ` that define uniqueness that is used during de-duplication. .. _glossary_substitution: Substitution ============ Substitution enables a :ref:`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 :ref:`Snippet Framework ` would automatically replace the text with the value. .. _glossary_syntax: Syntax ====== A Syntax is a :ref:`step-type ` that converts the :ref:`Snippet Argument ` into something the :ref:`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. ``:``. When using the ``low_code`` Syntax, the Snippet Argument would look like this: .. code-block:: yaml low_code: # Syntax name followed by colon delimiter version: 2 # Snippet argument content