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 (
).
Home
The Dashboards page is the default Home page (
) when you first launch SL1. You can set any of the top-level pages that display in the left-hand navigation bar as your landing page, including Events, Devices, Business Services, Skylar AI, Maps, and Setup and Config. You can also set a specific dashboard from the Dashboards page as your home page.
If you lose permission to the page or dashboard you set as your landing page, the Events page will be automatically set as your home page.
You cannot use any pages that display in the navigation bar below these pages as a landing page. This feature does not work with classic dashboards. For more information on what you can see and do on the default dashboards page,
To set your home page:
- In SL1, navigate to the page or the SL1 dashboard that you want to set as your home page.
- Click your user name in the navigation bar at the top of the page and select Set as Home Page. That page or dashboard will be your home page the next time you launch SL1. If the page you are currently on cannot be used as a home page, the Set as Home Page option will be grayed out.
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.
To navigate to the Dashboards page, click the Dashboards icon (
). You can also access "classic" dashboards from the Classic Dashboards page (Dashboards > Classic Dashboards).
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.
For more information about Dashboards, see the
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
Devices
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.
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
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
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
The SL1 Agent
The SL1 agent is a program that you can install on a device monitored by SL1. There is a Windows agent, an AIX agent, a Solaris 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.
The following minimum agent versions are required for SL1 12.1.1 and later: Windows version 131; Linux version 174; AIX version 180; and Solaris version 180.
For more information about the agent, see the
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:
- Device Service. Monitors a set of related devices, such as all devices from a specific region.
- IT Service. Monitors a service that IT provides to your organization. An IT service is made up of one or more device services.
- 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
Skylar AI
Skylar AI is a software services suite powered by artificial intelligence (AI) that is designed to automatically manage and anticipate IT incidents. Skylar AI reasons over telemetry and the stored knowledge of an organization to deliver accurate insights, recommendations, and predictions.
SL1 collects data and leverages Skylar AI to learn the patterns for a particular device metric over a period of time. Skylar uses the resulting data to build a device metric-specific model that is used to define a scope of expected behavior as well as anomalous data points.
The Skylar AI family of services currently includes the following components:
- Skylar Analytics, an advanced reporting and custom analytics service that combines AI-powered analytics with deep data exploration and visualization.
- Skylar Automated Root Cause Analysis (RCA), a log-based root cause identification and analysis service powered by unsupervised AI.
For more information about Skylar AI, see the Skylar AI Product Documentation site.
Skylar Analytics
Skylar Analytics contains a set of tools that lets you view, analyze, and use the data that SL1 gathers and sends to the Skylar AI engine. Skylar Analytics insights are presented in the SL1 user interface, using a ScienceLogic-hosted instance of Apache Superset, and in the Skylar AI API.
Skylar Analytics includes the following components:
- Data Visualization contains dashboards and charts based on data gathered by Skylar AI and SL1. Currently, this data includes server-focused metrics and basic network interface metrics, with more metrics planned for future Skylar updates. Please note that the dashboards in Business Intelligence (BI) tools are independent of SL1 dashboards or reports. Data Visualization is achieved using a ScienceLogic-hosted instance of Apache Superset or with your own third party tool.
- Data Exploration enables third-party tools that use the Microsoft Open Database Connectivity (ODBC) interface to access the metric data from Skylar AI. This component lets you use ODBC to connect Skylar AI data with applications like Tableau, Microsoft Power BI, or other business intelligence tools.
- Anomaly Detection uses Skylar AI to identify unusual patterns that do not conform to expected behavior. Anomaly Detection provides always-on, unsupervised, machine-learning-based monitoring that automatically identifies unusual patterns in the real-time performance metrics and resource data that it observes. Anomalies do not necessarily represent problems or events to be concerned about; rather, they represent unexpected behavior that might require further investigation.
- Predictive Alerting generates events in SL1 that forecast when a future event could happen, instead of reporting on an event that has already occurred. SL1 will display capacity predictions and even automate run book automations based on anticipation of out-of-capacity events before they become a production issue. Predictive alerts are based on real-time data analyzed by Skylar AI against expected device metrics.
Skylar Automated RCA
Skylar Automated RCA (Root Cause Analysis) uses unsupervised machine learning on logs to automatically find the root cause of software problems. It does not require manual rules or training, and it typically achieves accuracy within 24 hours.
As Skylar Automated RCA ingests logs, the Skylar artificial-intelligence (AI) engine analyzes the logs, looking for abnormal log line clusters that resemble problems, such as abnormally correlated rare and error events from across all log streams.
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
Setup and Config
The Setup and Config page (
) displays all information relevant to getting started in SL1 for administrator-level users. Included on this page are a number of journeys, intuitive self-service workflows that will guide you through the most common SL1 system tasks. Click the name of a workflow to get started.
This page also contains informational cards that provide you with the proper resources for SL1 setup and configuration.
The informational cards on this page include:
- Get Started. Displays a list of available user journeys and their journey status. Click the name of the journey to get started. The journeys include:
- Take a Tour of SL1
- Discover and Monitor Hybrid Cloud Infrastructure
- Resources. Hosts additional external resources to help you with setup and configuration; these links include:
- Training Portal
- ScienceLogic Support
- Overview. Provides links to the user journeys. These journeys include guided tours and interactive wizards that help you set up and refine your SL1 environment:
- Next Steps. Contains links to other pages in SL1 where you can continue working after completing some or all of a journey:
- Manage Devices
- Manage Collector Groups
- Manage Organizations
- Manage Users
- Manage Access Hooks
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
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).
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
For more information about Reports, see the
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).
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.
For more information about Organizations and Users, see the
Run Book 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
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
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
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