Overview of SL1 Features

Download this manual as a PDF file

This section provides an overview of the features and terminology in SL1.

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

SL1 Architecture

In a Distributed system, there are four general functions that an SL1 appliance can perform: user interface, Database Server, Data Collector, and Message Collectors. In large SL1 systems, dedicated nodes or appliances perform each function. In smaller systems, some nodes or appliances perform multiple functions. In the All-In-One Appliance system, a single SL1 node or appliance performs all four functions.

User Interface

Administrators and users access the user interface through a web browser. In the user interface, you can view collected data and reports, define organizations and user accounts, define policies, view events, and create and view tickets, among other tasks. The node or appliance that provides the user interface also generates all scheduled reports and provides access to the ScienceLogic API. The following nodes or appliances provide the user interface:

  • All-In-One Appliance. An All-In-One Appliance performs all functions, including providing the user interface.
  • Database Server. A Database Server can provide the user interface in addition to its database function.
  • Administration Portal. A dedicated Administration Portal node or appliance can provide the user interface.

NOTE: The Administration Portal communicates only with the Database Server and no other SL1 appliance. All connections between the Administration Portal and the Database Server are encrypted in both directions.

Database Server

The node or appliance that provides the database function is responsible for:

  • Storing all configuration data and policy data.
  • Storing performance data collected from managed devices.
  • In a distributed system, pushing data to and retrieving data from the nodes or appliances responsible for collecting data and collecting messages.
  • Processing and normalizing collected data.
  • Allocating tasks to the other nodes or appliances in the SL1 System.
  • Executing some automation actions in response to events.
  • Sending all email generated by the system.
  • Receiving all inbound email for events, ticketing, and round-trip email monitoring.

The following appliances can perform these database functions:

  • All-In-One Appliance. An All-In-One Appliance performs all functions.
  • Database Server. A dedicated Database Server provides all database functions.

Data Collection

Data Collectors are the SL1 nodes or appliances that retrieve data from monitored devices. In a distributed system, nodes or appliances that perform the data collection function also perform some pre-processing of collected data and execute automation actions.

The following appliances can perform the collection function:

  • All-In-One Appliance. An All-In-One Appliance performs all functions.
  • Data Collector. One or more Data Collectors are configured in collector groups for resilience. A collector group can be configured such that if an individual collector fails, other members of the group will pick up and share the load (N+1). A Data Collector can also perform the message collection function.

NOTE: The SL1 Agent can also be used to collect data from devices on which it can be installed. See the System Requirements page of the Support Site for a complete list of operating systems and versions supported by the agent. You can collect data from devices using only Data Collectors, using only the SL1 Agent, or using a combination of both.

Message Collection

The SL1 appliances that receive and process inbound, asynchronous syslog and trap messages from monitored devices.

The following nodes or appliances can perform the message collection function:

  • All-In-One Appliance. An All-In-One Appliance performs all functions.
  • Message Collector. A dedicated Message Collector receives and processes inbound, asynchronous syslog and trap messages from monitored devices.
  • In distributed systems that use the SL1 agent, the Message Collector passes agent data to the Database server. On these distributed systems, the Message Collector must be a stand-alone node or appliance, not a combination Data Collector/Message Collector.
  • Data Collector. A Data Collector can also perform the message collection function in addition to the data collection function.

API

SL1 provides a REST-based API that external systems can use to configure SL1 and access collected data. For example, the API can be used to automate the provisioning of devices in SL1.

The API is available through the Administration Portal, the All-In-One Appliance, and the Database Server.

For more information about SL1 architecture, see the Architecture section.

SL1 Extended Architecture

SL1 Extended Architecture includes additional types of SL1 nodes or appliances. The following SL1 features require the SL1 Extended Architecture:

  • Expanded Agent Capabilities. You can configure the SL1 Agent to communicate with SL1 via a dedicated Message Collector. However, this configuration limits the capabilities of the SL1 Agent. If you configure the SL1 Agent to communicate with SL1 via a Compute Cluster, you expand the capabilities of the SL1 Agent to include features like extensible collection and application monitoring.
  • Data Pipelines. Data pipelines transport and transform data. Data transformations include enrichment with metadata, data rollup, and pattern-matching for alerting and automation. The Data Pipelines provide an alternative to the existing methods of data transport (data pull, config push, streamer, and communication via encrypted SQL) in SL1. Data pipelines introduce message queues and communicate using encrypted web services.
  • Publisher. Publisher enables the egress of data from SL1. Publisher can provide data for long-term storage or provide input to other applications the perform analysis or reporting.
  • Scale-out storage of performance data . Extended Architecture includes a non-SQL database (Scylla) for scalable storage of performance data.
  • Anomaly Detection and future AI/ML developments. Anomaly detection is a technique that uses machine learning to identify unusual patterns that do not conform to expected behavior. SL1 does this by collecting data for a particular metric over a period of time, learning the patterns of that particular device metric, and then choosing the best possible algorithm to analyze that data. Anomalies are detected when the actual collected data value falls outside the boundaries of the expected value range.

SL1 Extended Architecture includes the following additional SL1 nodes or appliances:

Compute

Compute nodes are the SL1 appliances that transport, process, and consume the data from Data Collectors and the SL1 Agent. SL1 uses Docker and Kubernetes to deploy and manage these services. T

Load Balancer

A load balance is the SL1 node or appliance that brokers communication with services running on the Compute Cluster. Services running on the Compute Cluster are managed by Kubernetes. Therefore, a single service could be running on one Compute node in the Compute Cluster; to provide scale, multiple instances of a single service could be running on one, many, or all nodes in the Compute Cluster. To provide scale and resiliency, you can include multiple Load Balancers in your configuration.

Storage

SL1 Extended includes a Storage Cluster that includes multiple Storage Nodes and a Storage Manager. These SL1 nodes or appliances provide a NoSQL alternative to the SL1 relational database. The Storage Cluster can store performance and log data collected by the Data Collectors and the SL1 Agent.

Management

The Management Node allows administrators to install, configure, and update packages on the Compute Nodes cluster, Storage Nodes , and the Load Balancer. The Management Node also allows administrators to deploy and update services running on the Computer Cluster.

The SL1 Agent

The SL1 agent is a program that you can install on a device monitored by SL1. There is a Windows agent and a Linux agent. The agent collects data from the device and pushes that data back to SL1.

Similar to a Data Collector or Message Collector, the agent collects data about infrastructure and applications.

You can configure an agent to communicate with either the Message Collector or the Compute Cluster.

In the SL1 Extended Architecture (which includes Compute Nodes, Storage Nodes, and a Management Node), the Gen 3 agent collects the following data:

  • Device Availability. SL1 can determine the availability state of a device (available or unavailable) and generate trended availability graphs based on uptime data collected by the agent.
  • Logs. The SL1 agent can be configured to push logs to SL1 that match specific criteria from a log file or the Windows Event Log. You can view logs collected by the SL1 agent on the Logs pane of the Device Investigator page. The same logs also appear on the Logs tab in the Device Properties and Device Summary pages for that device. You can define event policies that specify how logs collected by an agent will trigger events.

  • Host Performance Metrics. Using Dynamic Applications, SL1 translates data provided by an SL1 agent to trend the following metrics:
    • Overall CPU Utilization
    • CPU Utilization Breakdown
    • Disk Average Queue Length
    • Disk IO Utilization
    • Memory Utilization
    • Network Bytes Read
    • Network Bytes Written
    • Storage Available
    • Storage Total
    • Storage Utilization
    • Swap Utilization

    You can view these metrics on the Device Investigator page and the Performance tab of the Device Summary panel for a specific device.

  • Host Configuration. Using a Dynamic Application, SL1 collects the following configuration data based on data provided by the SL1 Agent:
    • The number and speed of the installed CPUs
    • The amount of installed memory
    • The overall and per-disk storage size
    • The total swap capacity (SL1 Extended Architecture only)

    You can view the collected configuration data on the Configs tab of the Device Investigator page and the Device Summary panel.

  • Network Interface. The SL1 agent collects a list of the network interfaces running on the device. You can view the list of interfaces on the Interfaces tab of the Device Investigator page and the Device Summary page. This list includes attributes such as the interface MAC address, IP address, position, and speed as well as inbound and outbound utilization, number of errors, and discard and usage percentage.
  • File System. The SL1 agent collects data about the of configuration of the file systems found within a device, such as name, size and, type as well as utilization data such as free space, size, and usage percentage. You can view the file system data on the Hardware? tab of the Device Investigator page and the Device Summary page.
  • System Processes. The SL1 agent collects a list of all processes running on the device, such as name, process ID (PID), and state. You can view the list of processes on the Processes tab of the Device Investigator page and the Processes tab of the Device Summary page. Monitoring policies can be configured to trend and alert on process availability, process CPU usage, and process memory usage.
  • Windows Services. The SL1 agent collects a list of all Windows services enabled on the device. This list includes attributes such as the service name and run state. You can view the list of Windows Services on the Services tab of the Device Investigator page and the Device Summary page.
  • Installed Software. The SL1 agent collects a list of the software running on the device. This list includes attributes such as software name, version, and installation date. You can view the list of software on the Software tab of the Device Investigator page and the Device Summary page.

Organizations and Users

All policies, events, tickets, users, and other elements in SL1 are associated with an organization. An organization is a group for managing elements and user accounts.

The basic characteristics of an organization are:

  • A unique name (required).
  • Users who are members of the organization.
  • Elements (for example, devices) associated with the organization.

Organizations can be defined by geographic areas, departments, types of devices, or any structure that works best for your needs. For example, for a business with multiple locations, an administrator might create organizations named Boston, New York, and DC. Another administrator might create organizations named for departments, like Finance, Sales/Marketing, and Engineering.

Users

In SL1, there are two broad types of user accounts:

  • Administrators. By default, users of type "administrator" are granted all permissions available in SL1. Administrators can access all tabs and pages, and perform all actions and tasks on all entities, regardless of organization.

  • Users. Accounts of type "user" are assigned key privileges. Key privileges are customizable by the administrator and grant users access to pages and tabs and permit users to view information and perform tasks in SL1. These key privileges are defined by the SL1 system administrator from the Access Keys page (System > Manage > Access Keys).

For more information, see the section on Access Permissions.

An account of type "user" can be granted the privileges that allow him/her to create or modify other users' accounts. However, for accounts of type "user", certain restrictions apply:

  • An account of type "user" cannot create or modify an account of type "administrator".
  • An account of type "user" cannot change his/her own account to type "administrator" or change another user's account to type "administrator".
  • An account of type "user" cannot add additional Access Keys to his/her own account.
  • An account of type "user" cannot grant or remove Access Keys to other accounts that he/she has not also been granted.

Regardless of access keys, accounts of type "user" can access only pages and actions associated with their organization. For example:

  • Suppose your organization includes three regional offices. Suppose you define three organizations: Northeast, Headquarters, and West Coast.
  • Suppose each organization includes the hardware located at the corresponding office.
  • Now suppose the account "JohnDoe" is of type "user" and is a member of the organization "West Coast". User JohnDoe would be able to view and act upon only devices that are included in the organization "West Coast". User JohnDoe would not be able to view or act upon the hardware at the other offices.
  • SL1 allows you to assign each user a primary organization and optional additional organizations.
  • Now suppose that user "JohnDoe" needs to view the status of a device at headquarters. If you add "Headquarters" as a secondary organization in JohnDoe's account information, that user will now be able to view and act upon all the devices in the "Headquarters" organization.

NOTE: You can use Access Keys to further limit the access of each user, even within his/her own organization.

For more information about Organizations and Users, see the Organizations and Users section.

Credentials

Credentials are access profiles (usually username, password, and any additional information required for access) that allow SL1 to retrieve information from devices and from software applications on devices. Discovery uses SNMP credentials to retrieve SNMP information during initial discovery and nightly auto-discovery. If SL1 can connect to a device with an SNMP credential, SL1 deems that device "manageable" in SL1.

Dynamic Applications use credentials to retrieve SNMP information, database information, SOAP information, XML information, XSLT information, and WMI information. Proxied Web Services use SOAP/XML Host credentials to pass authentication information to external web services.

SL1 includes a type of credential called "Basic/Snippet" that is not bound to a specific authentication protocol. You can use this type of credential for Dynamic Applications of type "WMI", of type "snippet", and when defining system backups. "Basic/Snippet" credentials can also be used for monitoring Windows devices using PowerShell.

SL1 includes a type of credential that allows Dynamic Applications of type "Snippet" to use SSH to communicate with a remote device. To use these Dynamic Applications, you must define an SSH credential.

SL1 includes a type of credential that allows Dynamic Applications to retrieve data from Windows devices. If you align a Dynamic Application for PowerShell with a PowerShell credential, SL1 assumes that you want to use its built-in agentless transport to communicate with Windows devices.

If necessary, a single device can use multiple credentials. If more than one agent or application is running on the device, each agent or application can be associated with its own credential. During discovery, SL1 will use the appropriate credential for each agent.

For more information about Credentials, see the Discovery and Credentials section.

Discovery

Discovery is the tool that automatically finds all the hardware-based devices, hardware components, and software applications in your network. You must provide the discovery tool with a range or list of IP addresses and/or a list of fully-qualified domain names (hostnames), and the discovery tool determines if a device, hardware component, or software application exists at each IP address. For each device, hardware component, or software application the discovery tool "discovers", the discovery tool 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 about the device.

The Discovery tool also determines which (if any) Dynamic Applications to align with the device. If the discovery tool finds Dynamic Applications to align with the device, the discovery tool triggers collection for each aligned Dynamic Application.

For more information about Discovery, see the Discovery and Credentials section.

Device Administration

As part of monitoring your network, SL1 collects data using common networking protocols. Most collected data is associated with a device in SL1. A device in SL1 is a record that can represent:

  • Physical network hardware, for example, servers, switches, routers, printers, etc.
  • A component of a larger system, for example, a data store in a hypervisor system, a blade server, etc.
  • Any other entity about which you want to collect data, but want or need to associate that data with a container that does not correspond directly to a physical device or a component. For example, you might configure a device record that represents a web site or a cloud service.

SL1 allows you to monitor and manage hardware and applications within your network. SL1 provides a network-wide view through a "single pane of glass." This means that you can monitor status, create policies, define thresholds, and receive notifications, all through a single, browser-based application.

Virtual Device

A virtual device is a container for collected data. A virtual device can be used when you want to:

  • Monitor a device or application that doesn't support TCP/IP, SNMP, or both. The device's data can be pushed to SL1 via another method (for example, email) and stored in a virtual device.
  • Monitor multiple SNMP agents on a single device. In such a case, one of the SNMP agents (for example, a hardware agent) can be associated with the device and another SNMP agent (for example, an agent that monitors a software application) can be associated with a virtual device.
  • Isolate and monitor specific parameters separately from their originating device. For example, you might want to monitor a database and keep its data separate from the hardware data you are collecting from the host device.

Component Device

SL1 uses Dynamic Applications to retrieve data from a management device 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.

  • In SL1 a managed entity is called a component device. A component device is an entity that runs under the control of a physical management device.
  • In SL1, the root device is the physical device that manages one or more component devices.
  • In SL1, 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.

For more information about Devices, see the Device Management section.

Business Services

A business service includes one or more technical services that provide value to internal or external customers. Some examples of business services include verifying Internet access or website hosting, online banking, remote backups, and remote storage. Usually a business service includes an associated Service Level Agreement (SLA) that specifies the terms of the service.

Create the following types of services on the Business Services page, in the following order:

  1. Device Service. Monitors a set of related devices, such as all devices from a specific region.
  2. IT Service. Monitors a service that IT provides to your organization. An IT service is made up of one or more device services.
  3. Business Service. Monitors a service your organization provides to your customers. A business service is made up of one or more IT services.

For more information about Business Services, see the Business Services section.

Events

One of the quickest ways to monitor the health of your network is to look at events. You can view events on the Events page in SL1.

Events are messages that are triggered when a specific condition is met. For example, an event can signal if a server has gone down, if a device is exceeding CPU or disk-space thresholds, or if communication with a device has failed. Alternately, an event can simply display the status of a managed element.

SL1 generates log messages from incoming trap and syslog data, and also when SL1 executes user-defined policies. SL1 then uses these log messages to generate events. SL1 examines each log message and compares it to each event definition. If a log message matches an event's definition, SL1 generates an event instance and displays the event on the Events page.

Each event includes a description of the problem, where the problem occurred (device, network hardware, software, policy violation), a pre-defined severity, the time of first occurrence, the time of most recent occurrence, and the age of the event.

SL1 includes pre-defined events for the most commonly encountered conditions in the most common environments. You can also create custom events for your specific environment or edit the pre-defined events to better fit your specific environment.

For more information about Events, see the Events section.

Automation

SL1 includes automation features that allow you to specify actions you want SL1 to execute automatically when specific event conditions are met. Automation in SL1 is divided into two parts:

  • An automation policy defines the event conditions that can trigger an automatic action.
  • An action policy defines an action that can be triggered by an automation policy. An action policy can perform one of the following tasks:
  • Send an email message to a pre-defined list of users and/or external contacts.
  • Send an SNMP trap from SL1 to an external device.
  • Create a new ticket (using ticket templates defined in the Ticket Templates page [Registry > Ticketing > Templates]).
  • Update an existing ticket. An action policy can change the status and/or severity of an existing ticket and/or add a note to an existing ticket. For this action policy to trigger successfully, a ticket must be associated with the event that triggered the action.
  • Write an SNMP value to an existing SNMP object on an external device.
  • Query a database.
  • Run a custom python script, called a snippet.
  • Send an SNS Message to a Topic ARN (Amazon Resource Name). All subscribers to the Topic ARN will receive the message.

For more information about Automation, see the Run Book Automation section.

Machine Learning-based Anomaly Detection

Anomaly detection is a technique that uses machine learning to identify unusual patterns that do not conform to expected behavior. SL1 does this by collecting data for a particular metric over a period of time, learning the patterns of that particular device metric, and then choosing the best possible algorithm to analyze that data.

SL1 uses the resulting combination of collected data and the auto-selected algorithm to build a model that is unique to that specific device and metric. That model is then used to anticipate the expected behavior for that device metric. Anomalies are detected when the actual collected data value falls outside the boundaries of the expected value range. SL1 then continuously refines the model as it collects more data.

Anomalies do not necessarily represent problems or events to be concerned about; rather, they represent unexpected behavior that you might want to investigate.

Machine learning-based anomaly detection is available only in SL1 Premium solutions. To upgrade, contact ScienceLogic Customer Support.

For more information about Machine Learning-based Anomaly Detection, see the Machine Learning-based Anomaly Detection section.

Dynamic Applications

Dynamic Applications are the customizable policies that tell SL1 what data to collect from devices and applications. For example, suppose you want to monitor a MySQL database running on a device in your network. Suppose you want to know how many insert operations are performed on the MySQL database. You can create or edit a Dynamic Application that monitors inserts. Every five minutes (for example), SL1 could check the number of insert operations performed on the MySQL database. SL1 can use the retrieved data to trigger events and/or to create performance reports.

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

Dynamic Applications in SL1 support a variety of protocols to ensure that SL1 can always communicate with the devices and applications in your network and retrieve information from them. Dynamic Applications can use the following protocols to communicate with devices:

  • SNMP

  • SQL
  • XML
  • SOAP
  • XSLT (uses SOAP and XSLT to convert XML data to a new format)
  • WMI (Windows Management Instrumentation), including WMI and WBEM
  • Windows PowerShell
  • Custom Python applications (called "snippets") for proprietary or more complex data retrieval

For more information about Automation, see the Run Book Automation section.

PowerPacks

A PowerPack is an exportable and importable package of one or more Dynamic Applications, device classes, device templates, event policies, custom reports, dashboard widgets, dashboards, run book policies, run book actions, ticket templates, credentials, proxy XML transformations, themes, device categories, device dashboards, and/or IT service policies.

You can use PowerPacks to share customized content among SL1 systems and to download customized content from ScienceLogic.

You can create a PowerPack on a SL1 system to export one or more Dynamic Applications, device classes, device templates, event policies, custom reports, dashboard widgets, dashboards, run book policies, run book actions, ticket templates, credentials, proxy XML transformations, themes, device categories, device dashboards, and/or IT service policies. You can then import that PowerPack on another SL1 system to install the Dynamic Applications, device classes, device templates, event policies, custom reports, dashboard widgets, dashboards, run book policies, run book actions, ticket templates, credentials, proxy XML Transformation, themes, device categories, device dashboards, and/or IT service policies.

For more information about PowerPacks, see the PowerPacks section.

Maps

A map is a visual representation of the various devices and related elements, also called nodes, in your environment that have been discovered by SL1. A map displays the important details about the nodes, their hierarchy, and the relationships associated with those nodes.

Maps can display business services, component maps (DCM, DCM+R), CDP topology, LLDP topology, Layer-2 topology, Layer-3 topology, and Virtual Infrastructure (VMware and virtual machines).

You can also create your own maps with your most important devices, and add images, text, and shapes to customize your maps.

To view a map, go to the Maps page () and click the name of the map from the Maps page.

A map includes the following graphical elements:

  • Nodes. Shapes that represent Devices, Topology Elements, and Business Services defined in SL1. The shape of a node represents its type, and the color of its outline specifies the current state of the node.
  • Links. Lines with or without arrows that represent the relationships and hierarchies between nodes. All device relationships are displayed as child and parent relationships. If the nodes on a map contain arrows, then the arrows represent the direction of the relationship, pointing from the child node to its parent node. If a node does not contain an arrow, then the relationship is bi-directional, or undirected.

For more information about Maps, see the Maps section.

Dashboards

A dashboard is a page that displays one or more graphical reports, called widgets. These widgets appear in their own pane, and display charts, tables, and text. Access to dashboards is based on your login credentials, so you can view only dashboard data for which you have access. Also, some dashboards might be private instead of public.

To define a widget, you first select from a list of pre-defined widget definitions, and then customize what will be displayed by the selected widget by supplying values in the option fields provided by that widget.

If an animated line appears under a widget name, the widget is in the process of updating its data. When the line disappears, the widget is done updating.

If an item name displays as a hyperlink in a dashboard, you can click that link to go to the relevant detail or Investigator page for that item. You can click dashboard links to the Investigator pages for devices, events, and services.

To navigate to the Dashboards page, click the Dashboards icon (). You can also access "classic" dashboards from the Classic Dashboards page (Dashboards > Classic Dashboards):

For more information about Dashboards, see the Dashboards section.

Reports

Custom Reports

A custom report in SL1 provides you with a collection of data from one or more tables in the SL1 database. This information is populated and generated in different user-defined formats. You can select from default custom reports provided by ScienceLogic, edit these default reports, or create your own reports. You can also schedule reports, view a list of archived reports, and email reports to other users.

Custom reports include Quick Reports, which are custom report templates in SL1. You can access Quick Reports on the Reports page, in the Run Report category (Reports > Run Report).

A report includes three components:

  • An input form where you select the options and data you want to include in the report.
  • An .ods output template that specifies the format of the generated report.
  • Gluecode, the code that specifies how to handle your input, which data to retrieve, and any processing that needs to be performed on the data.

SL1 includes predefined reports, with defined forms, output templates, and the gluecode. These predefined reports can be modified, and you can create your own custom reports.

Embedded Reports

Several pages in SL1 allow you to generate a report that contains the information displayed in the page. Reports that are specific to a page are called embedded reports. The embedded reports cover the following elements:

  • Devices
  • Device Interfaces
  • System Processes
  • Windows Services
  • Hardware Components
  • Installed Software
  • Organizations
  • User Accounts
  • Access Keys
  • Tickets
  • Asset Records
  • Product Subscriptions
  • Vendors

If a feature includes embedded reports, the SL1 page for that feature will include a Reports button. Also, the section in the documentation that covers that feature will include a description of the embedded reports for that feature.

For more information about Reports, see the Reports section.

Ticketing

A ticket is a request for work. This request can be in response to a problem that needs to be fixed, for routine maintenance, or for any type of work you require. Tickets are assigned a severity based on the severity of the issue that needs to be fixed or worked on. For example, a server going down might require a critical ticket, whereas a routine maintenance issue might require only a minor ticket. These severities range from healthy to notice, minor, major, and critical.

A ticket can be created manually, or created based on an event. If a ticket is created based on a selected event, most of the ticket fields are populated automatically by SL1. The SL1 can also automatically create a ticket, using Run Book Automation and user-defined parameters.

In SL1 you can view a list of active tickets, create new tickets, edit one or more existing tickets, and generate reports for one or more tickets, among other features.

For more information about Ticketing, see the Ticketing section.

Asset Management

An asset is a piece of equipment owned by an organization. An asset record is a collection of information about that asset. In SL1, asset records are usually created for hardware devices, with some of the information populated automatically from collected data. Users can also manually enter information into an asset record.

In SL1, asset records can contain information about:

  • The name, make, and model of a device.
  • The serial number of a device.
  • Function and status of a device.
  • Networking information, like host ID, IP address, or DNS server for the device.
  • Physical location of the device.
  • Description of the network interface.
  • Vendor information for the device, including PO or check number, warranty policy, and service policy.
  • Hardware information like the amount of memory, CPU, and BIOS or EPROM version.
  • Description of each hardware component (if applicable).
  • Description of installed software (if applicable).

When possible, SL1 can automatically populate fields in each asset record. SL1 also allows users to create their own tabs and form fields in addition to the ones provided by default.

For more information about Assets, see the Asset Management section.