Introduction to Dynamic Application Development

Download this manual as a PDF file

This section describes Dynamic Applications, which are customizable policies, created for a specific vendor and a specific type of device or system.

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 ().

What Is A Dynamic Application?

Dynamic Applications are customizable policies, created for a specific vendor and a specific type of device or system, that tell SL1:

  • What data to collect from devices
  • How to present the data that has been collected
  • When to generate alerts and events based on the data that has been collected

SL1 includes Dynamic Applications for the most common hardware and software. You can customize these default Dynamic Applications to best work in your environment. You can also create custom Dynamic Applications.

For example, a Dynamic Application that is designed to collect information about file system usage on a device might define that:

  • SL1 should collect the total size of each file system and amount of space used for each file system.
  • SL1 should use the two collected values to present a graph of "percentage used" values for each file system.
  • SL1 should generate an alert when the amount of space used on a file system exceeds a specified percentage of the total size of that file system.

Types of Dynamic Applications

There are many different types of Dynamic Applications that can be created and used in SL1. The Dynamic Application type defines:

  • The protocol SL1 should use to collect the data.
  • An archetype, which defines generally what type of data is being collected.

All Dynamic Application types use one of the following protocols:

  • Bulk Snippet. SL1 will collect data by executing custom code written in the Python programming language. A single instance of the Dynamic Application uses custom-written Python code to collect data from multiple devices. For a standard Snippet Dynamic Application, SL1 spawns a separate instance of the Dynamic Application for each device or component device. The Bulk Snippet is useful for systems that include a large number of component devices.
  • Database. SL1 will collect data by connecting to a database and executing a query.
  • Internal Collection. SL1 will collect data by performing an "Extended Internal Collection". Basic hardware and system data that was previously collected by SL1 using an internal SNMP process can now be collected with Internal Collection Dynamic Applications (ICDAs). ICDAs do not use SNMP to provide a way to collect basic hardware and system data from devices that do not support SNMP.
  • PowerShell. SL1 will collect data from a Windows device by performing PowerShell commands.
  • Snippet. SL1 will collect data by executing custom code written in the Python programming language.
  • SNMP. SL1 will collect data by performing SNMP requests.
  • SOAP. SL1 will collect data by sending HTTP POST requests to a SOAP web service.
  • WMI. SL1 will collect data by sending requests to a Windows Management Instrumentation service running on an external Windows device.
  • XML. SL1 will collect data by sending an HTTP GET request for an XML document.
  • XSLT. Similar to the SOAP protocol, SL1 will collect data by sending HTTP POST requests to a SOAP web service. SL1 will also perform XSLT transformations to generate the requests and parse the responses.

All Dynamic Application types use one of the following archetypes:

  • Performance. SL1 will display the collected data in a historical graph. SL1 will also automatically calculate daily normalized data for each graph.
  • Configuration. SL1 will display the current values of the collected data in tabular format. SL1 will store tables of previously collected data to show when the values have changed.
  • Journal. SL1 will display collected data in log format. Each log entry can contain multiple collected values and can change over time. The Journal archetype is available only when using the Snippet protocol.

Each Dynamic Application type has unique configuration options.

Elements of a Dynamic Application

A Dynamic Application can contain the following elements:

  • Properties that define general settings for the Dynamic Application. For example, the name of the Dynamic Application, type of Dynamic Application (protocol and archetype), and frequency at which SL1 should collect data using the Dynamic Application.
  • Collection Objects that define each value SL1 should collect, how SL1 should collect the value, and any processing SL1 must perform before storing the value. For Dynamic Applications with an archetype of Configuration, Collection Objects also define how each value will be displayed in the table of data.

  • Requests or Snippets that define how SL1 should request data from a device. For Dynamic Application types that use Requests or Snippets, each Collection Object is associated with the Request or Snippet that will populate that Collection Object. Requests are used in Dynamic Applications that use the SOAP, WMI, or XSLT protocol. Snippets are used in Dynamic Applications that use the Snippet protocol.
  • Presentation Objects that define how SL1 should present the collected data (for Dynamic Applications with an archetype of Performance or Journal).
  • Alerts that include formulas that SL1 will evaluate each time data is collected. Each formula examines the current values for one or more Collection Objects. If the formula evaluates to true, SL1 generates an alert. Additionally, you can align an event policy with each Alert, and SL1 can trigger that event if the alert evaluates to true.
  • Thresholds that define variables that can be used in Alerts. Each Threshold defines an allowed range of values for the variable and a default value. The value of the Threshold variable can be changed on a per-device basis by users of the Dynamic Application, without having to modify the Dynamic Application.

Optional Features for Dynamic Applications

You can enable the following optional features for a Dynamic Application:

  • Dynamic Component Mapping. SL1 can use Dynamic Application data that has been collected from a single management system, such as a VMware ESX server, to create a device record for each entity (such as a virtual machine) managed by that single management system. For more information, see the Dynamic Component Mapping section.
  • Caching. When SL1 requests information from a device during Dynamic Application collection, SL1 can optionally cache the response from the device. If a response is cached, other Dynamic Applications that use the same protocol can use the cached response to populate collection objects. Caching responses reduces the number of requests performed by SL1 and speeds up collection. For more information, see the Caching section.
  • Collector Affinity. SL1 enables you to specify which Data Collectors are allowed to collect data from a device for a Dynamic Application. This ensures that a group of collection jobs that cannot be split up among multiple Data Collectors—for instance, Dynamic Applications that produce and consume cache—will run on a single Data Collector. For more information, see the Dynamic Application Settings section.
  • Relationships. Dynamic Applications can be configured to automatically create relationships between devices. For example, the Dynamic Applications in the VMware vSphere and NetApp PowerPacks are configured to create relationships between VMware Datastore component devices and their associated NetApp Volume component devices. Relationships created by Dynamic Applications are used and visualized by SL1 in the same manner as relationships created by topology collection, Dynamic Component Mapping, and manually in the user interface. For more information about Relationships, see the Dynamic Application Relationships section.
  • Collection Labels. When multiple Dynamic Applications collect the same type of performance data from different devices, you can use collection labels to view data from those different Dynamic Applications at the same time. For example, when SL1 displays the CPU utilization, Memory utilization, or Swap utilization for a device, the utilization values come from a presentation object in a Dynamic Application aligned with that device. For more information about Collection Labels, see the Presentation Objects and Collection Labels sections.
  • Custom Attributes. Dynamic Applications of archetype configuration can collect configuration data and use that data to create and/or populate the value of a custom attribute. There are two ways Dynamic Applications can interact with custom attributes. A Dynamic Application can populate the value of an existing custom attribute, or a Dynamic Application can both create the custom attribute and populate its value. For general information on custom attribute, see the section on custom attributes.  For details on using a Dynamic Application to populate or create custom attributes, see the Collection Objects section.
  • Asset Linking. SL1 can use data collected by configuration Dynamic Applications to automatically populate fields in asset records. For more information about Asset Linking, see the Collection Objects section.
  • Inventory Linking. SL1 can use data collected using configuration Dynamic Applications to automatically populate inventories of hardware components and installed software. For more information about Inventory Linking, see the Collection Objects section.
  • Standard Deviation Alerting. SL1 can calculate standard deviation data for values collected by performance Dynamic Applications. The standard deviation data can generate alerts when values deviate by a specified amount. For more information about enabling standard deviation calculations for collected data, see the Collection Objects section. For more information about using standard deviation in alerts, see the Alerts and Thresholds section.