Introduction

Download this manual as a PDF file

This section describes how to use Internal Collection Dynamic Applications (ICDAs) to gather data from devices that do not support SNMP or to perform customized processing on collected SNMP data.

This section does not cover elements of Dynamic Application development that are common to all Dynamic Application types. You should be familiar with the common elements and concepts of Dynamic Applications before reading this section. For general information on planning, designing, using, and troubleshooting Dynamic Applications, see the Dynamic Application Development section.

Use the following menu options to navigate the SL1 user interface:

  • To view a pop-out list of menu options, click the menu icon ().
  • To view a page containing all of the menu options, click the Advanced menu icon ().

This section provides an overview of ICDAs. It contains the following topics:

What is an Internal Collection Dynamic Application?

SL1 has traditionally used SNMP and an internal process called "internal collection" to collect the following data for each device:

  • Availability and latency
  • System description, system uptime, and system local
  • Filesystem inventory and performance
  • Interface inventory and performance

However, you might need to monitor device data that is partially available through SNMP, or not available at all through SNMP.

For devices that do not support SNMP, SL1 provides an additional method to collect this data called Internal Collection Dynamic Applications (ICDAs). ICDAs combine the efficiency of internal collection with the flexibility of dynamic applications, ensuring uniform data across SL1.

How Do ICDAs Work?

Internal Collection Dynamic Applications align to devices in the same way as other Dynamic Applications. If the ICDA includes a discovery object, the ICDA automatically aligns with devices during discovery. You can also manually align ICDAs to devices and include ICDAs in device templates.

When SL1 begins an internal collection, it checks to see if any ICDAs are aligned. If ICDAs are aligned, SL1 performs an "Extended Internal Collection". The platform combines data it collected using ICDAs with data it collected using an internal SNMP process, and then the platform completes the collection process. 

The following illustration highlights the ICDA functionality in the collection process:

Image of the ICDA workflow

If SL1 collects this data using the SNMP-based internal collection and also collects this data using ICDAs, the data from ICDAs takes precedence.

The ICDA data that SL1 collects is stored in a database that is separate from the dynamic application database. ICDA results are stored where the corresponding internal collection would store its results.

ICDAs do not include presentation objects, thresholds, or alerts. SL1 evaluates alerts and events in exactly the same way as for standard internal collection.

Types of ICDAs

There are two types of Internal Collection Dynamic Applications:

  • Internal Collection Inventory. These ICDAs collect configuration data about filesystems, such as storage size, filesystem type, and storage used. These ICDAs also collect configuration data about interfaces, such as physical address, operational status, and IP addresses. In SL1, the available Data Models for this Application Type are Filesystem Inventory and Interface Inventory. Use these ICDAs to monitor inventory processes, like process_collect.py, which runs every 2 hours.
  • Internal Collection Performance. Collects data about availability and latency, device information (system description, system uptime, system local), filesystem performance, and interface performance.  In SL1, the available Data Models for this Application Type are Availability, Filesystem Performance, SNMP Detail (includes Uptime, Description, and Locale), and Interface Performance. Use these ICDAs to monitor performance collection processes, like process_check.py, which runs every 5 minutes.

The names for the ICDA Data Models follow the existing naming conventions used by the internal collection processes.

Snippets and Execution Environments

Internal Collection Dynamic Applications collect data by executing one or more blocks of Python code, called snippets. SL1 passes credential and other configuration information to the snippet, and at the end of execution, the snippet must pass collected data back to SL1. The Dynamic Application developer defines snippet code that collects data and processes data.

One way in which Dynamic Applications that use snippets are unique from most other types of Dynamic Applications is that they can be aligned with a specific execution environment.

In the SL1 user interface, an execution environment is a list of one or more ScienceLogic libraries. When a Dynamic Application snippet, Run Book Automation snippet, or credential test is executed, the execution environment defines a virtual Python environment that is deployed on-demand and includes all of the ScienceLogic libraries aligned with it for use during snippet execution.

When you create an Internal Collection Dynamic Application, you must select an execution environment to align with that Dynamic Application. All of the snippets contained in the Dynamic Application will then use that execution environment whenever the Dynamic Application runs. If you do not specify an execution environment, SL1 will align the Dynamic Application with the default System environment.

You can create and manage execution environments on the Environment Manager page (System > Customize > ScienceLogic Libraries > Actions > Execution Environments). For more information about creating and managing execution environments, see the section on Managing Execution Environments.

Data Collected by ICDAs

This section lists the collection objects included in each type of Data Model.

NOTE: For each Data Model, this list also describes how to index the collection objects so they can be merged with values from the internal, SNMP-based collection process. Ensure that you follow the indexing format. Improper indexing could result in duplicated entities if the two types of data cannot be merged.

The ICDA data takes precedence over any data collected during SNMP-based internal collection.

Internal Collection Inventory Application Types

Use these ICDAs to monitor inventory processes, like process_collect.py, which runs every 2 hours.

Filesystem Inventory

Index: Filesystem Name, such as /dev/sda1.

Objects:

  • Storage Size. Measured in storage units.
  • Filesystem Type. Type of filesystem, such as ext4.
  • Storage Used. Measured in storage units.
  • Storage Units. Measured in bytes per storage units.
  • Media Type. Type of media, such as CD, hard drive, or flash drive.

Interface Inventory

Index: SNMP interface index or user-defined unique index if only ICDA collects the data for the interface.

Objects:

  • Name. String.
  • Alias. String.
  • Descr. String.
  • Type. Interface type as defined in IF-MIB.
  • Phys Address. String for the MAC Address.
  • Speed. Measured in bps.
  • High Speed. Measured in Megabits per second, or Mbps.
  • Admin Status. Integer: up [1], down [2], testing[3].
  • Operational Status. Integer: up [1], down [2], testing[3], unknown [4], dormant [5], not present [6], lower layer down [7].
  • Connector Present. Integer.
  • 64-bit Support. True or false.
  • Blade. Blade number.
  • Port. Port number.
  • IP Addresses. IP Address and Subnet, such as [(1.2.3.4, 255.255.255.0), (2.3.4.5, 255.255.255.128)].

Internal Collection Performance Application Types

Use these ICDAs to monitor performance collection processes, like process_check.py, which runs every five minutes.

Availability

Index: None (this impacts the entire device, so there can only be only value per index).

Objects:

  • Availability. True or false, depending on whether the device is available.
  • Latency. Measures uptime in 10 millisecond increments.

SNMP Detail

Index: None (this impacts the entire device, so there can only be only value per index).

Objects:

  • System Description. String.
  • System Uptime. Measured in 10-millisecond increments.
  • System Locale. String.

Filesystem Performance

Index: Filesystem Name, such as /dev/sda1.

Objects:

  • Storage Used. Measured in storage units.

  • Storage Units. Measured in bytes per storage units.
  • Percent Used. Measured in percentage of storage used.

Interface Performance

Index: SNMP interface index or user-defined unique index if only ICDA collects data for the interface.

Objects:

  • Phys Address. String for the MAC Address.

  • Admin Status. Integer: up [1], down [2], testing[3].

  • Operational Status. Integer: up [1], down [2], testing[3], unknown [4], dormant [5], not present [6], lower layer down [7].
  • ifInOctets. Interface Inbound Traffic in octets.
  • ifOutOctets. Interface Outbound Traffic in octets.
  • ifInDiscards. Interface Inbound Discards.
  • ifOutDiscards. Interface Outbound Discards.
  • ifOutErrors. Interface Outbound Errors.
  • ifInErrors. Interface Inbound Errors.

Port Performance

Index: Data pair of port number and port protocol: TCP (0), UDP (1)

Objects:

  • State. Port state, up or down.

Process Inventory

NOTE: ICDA process data does not merge with agent-collected data.

Index: Process Pid number

Objects:

  • Name. String for the Process Name.
  • Arguments. String for the Process Arguments.
  • Path. String for the Process Path.
  • User. String for the Process User.
  • CPU Time. Integer.
  • Memory Use. Integer.
  • State. Integer.

Process Performance

NOTE: ICDA process data does not merge with agent-collected data.

Index: Process Pid number

Objects:

  • Name. String for the Process Name.
  • Arguments. String for the Process Arguments.
  • Path. String for the Process Path.
  • User. String for the Process User.
  • CPU Time. Integer.
  • Memory Use. Integer.
  • State. Integer.

Service Inventory

Index: Service Name

Objects:

  • Start Mode. String: Auto, Manual, Disabled, Anything Else.
  • State. Integer: 0 (running), 1 (not running).

Service Performance

Index: Service Name

Objects:

  • Start Mode. String: Auto, Manual, Disabled, Anything Else.
  • State. Integer: 0 (running), 1 (not running).