Global Settings

In SL1, global settings allow you to define default behavior that applies to all elements in the platform. For settings that affect devices, these global settings can be overridden by applying device-level settings.

SL1 includes global settings for:

API
SL1 appliances
Asset Automation
Logins, discovery, data collection, and expiration warnings
Data retention
Inbound email and outbound email
Login Alert Messages
Password Reset Emails
Thresholds for:

System latency, file system usage, counter rollovers, availability, and component devices
Interfaces
Class-based quality of service (CBQoS)

You can also define global settings for SL1 appliances, system backups, collector groups, and processes.

These global settings allow system administrators to define and automate best practices and SOPs for 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 ().

Global Settings for API

The REST API Settings page (System > Settings > API) allows you to define global parameters that affect the behavior of the REST API. When defined, these parameters affect all interaction with the API.

NOTE: This page is available only to administrator users.

To edit the settings in the REST API Settings page:

Go to the REST API Settings page (System > Settings > API).

In the REST API Settings page, edit the values in one or more of the following fields:

Internal Request Account. Specify the user account that allows SL1 to make API requests without a password.
X-EM7-run-as Header Support. Specifies whether administrator users can make API requests using the permissions of another user without that user's password. Choices are:

Disabled. Administrator users cannot make API requests using the permissions of another user.
Enabled (Admin only). Administrator users can include the X-EM7-run-as Header to make API requests using the permissions of another user.

Logging. Specifies which logs SL1 will write to when tickets are created or updated using the API. Choices are:

Transaction Logging Only (System Logs). If a ticket is created or updated using the API, SL1 will write the standard entry to the audit log that indicates a user performed a write-operation using the API. However, SL1 will not write to the ticket log for the ticket that was created or updated.
Normal (Ticket and System Logs). If a ticket is created or updated using the API, SL1 will write to the audit log and to the ticket log for the ticket that was created or updated.

X-EM7-suppress-logging Header Support. If Normal (Ticket and System Logs) is selected in the Logging field, this field specifies whether the X-EM7-suppress-logging header can be used when an administrator creates or updates a ticket using the API. If the X-EM7-suppress-logging header is used when creating or updating a ticket, SL1 will not write to the ticket log for the ticket that was created or updated. Choices are:

Disabled. The X-EM7-suppress-logging header cannot be used.
Enabled (Admin only). The X-EM7-suppress-logging header can be used to stop SL1 from writing to the ticket log for the ticket that was created or updated.

Send Notification. When a ticket is created or updated, SL1 can automatically send notification emails to the ticket assignee and ticket watchers. This option specifies the conditions under which SL1 will send notification emails when tickets are created or updated using the API. Choices are:

Only if X-EM7-send-notification:1 is sent. SL1 will send notification emails for a ticket only when the X-EM7-send-notification header is set to 1.
Sent after every write operation. SL1 will send notification emails for every API request that creates or updates a ticket.

Click the Save button to save changes in this page.

Global Settings for Appliances

The Appliance Manager page (System > Settings > Appliances) provides for global appliance configuration and management for your entire system or stack. This includes collector group and load distribution, version information, license status, and other items that are important when you upgrade.

From the Appliance Manager page, you can also access the Web Configuration Utility for each ScienceLogic appliance by clicking the toolbox icon(), or you can access the database administration tool for each Database Server or All-In-One Appliance by clicking the gear icon ().

For each Database Server, Data Collector, and Message Collector, you can click on the magnifying-glass icon () to view the output of the system status script for that appliance.

During upgrade, table cells will highlight known, pending action items that must be done to successfully complete an upgrade, such as highlighting an SL1 appliance that is running a different version of SL1 than the Database Server.

This page is useful for ensuring that every Data Collector is assigned to a Collector Group before you begin an upgrade. In some cases, the Data Collector might be assigned to an empty Collector Group, if the collector is new.

You can also use this page to ensure that Data Collector load is near or below the system requirements for each collector.

To edit and view information about an SL1 appliance:

Go to the Appliance Manager page (System > Settings > Appliances).
Locate the SL1 appliance you want to edit. Click its wrench icon (). The fields in the top pane are populated with values from the selected SL1 appliance.
You can edit one or more of the following fields:

Host Name. Name of the appliance.
IP Address. Primary IP address for the appliance.
Model Type/Module Type. Type of appliance. If an appliance is added with the wrong appliance type, SL1 generates a critical error to notify the user. The types include:

All In One Server
Database
Administration Portal
Data Collection Unit
Message Collection Unit

The combination appliance with a Database Server and an Administration Portal on a single appliance will appear with Module Type of Database. The combination appliance with a Message Collection Unit and a Data Collection Unit will appear with Module Type of Data Collection Unit.
Integration Server (SL1PowerFlow)

Description. Description of the appliance.

You can edit two optional fields for Data Collector or Message Collector.

DB User. User name that can access the MariaDB database on the Data Collector or Message Collector.
DB Password. Password that allows access the MariaDB database on the Data Collector or Message Collector.

If you are using AWS RDS with your SL1 System, you must define the DB User and DB Password for each Data Collector or Message Collector.

ScienceLogic recommends that you vary the Data Collector and Message Collector database credentials for enhanced per-appliance security. This greatly enhances the security of your central database by disallowing a successful attack to go unnoticed on your Data Collector and then succeed without failure on the central database.

The Appliance Manager page also displays the following columns:

Collector Group. For Data Collectors and All-In-One Appliances, specifies the Collector Group associated with the appliance.
Build. Specifies the latest build installed on the appliance.

If an SL1 appliance is running a different version of SL1 than the Database Server, the corresponding cell in the Build column will be highlighted.
MariaDB. Specifies the version of MariaDB running on the All-In-One Appliance, Database Server, Data Collector, or Message Collector.
Capacity. For Database Servers, specifies the licensed capacity of the appliance.
Allocation. For Data Collectors, specifies the number of devices aligned with the appliance.
ID. Unique numeric ID, automatically assigned by the platform to each appliance in the Appliance Manager page.
Validated. Specifies whether the license is valid.
Endpoint. SL1 Agent endpoint for the Gen 1 Agent.
Needs Reboot?. Specifies whether the appliance requires reboot to add latest kernel or security updates. This column is updated every 30 minutes. Hover your mouse to determine why the reboot is required and information about kernel version, packages, and last reboot.
Task Manager Paused? . Specifies whether the task manager service (em7) is paused. This value is updated every two minutes.
Edit Date. Date the appliance's information was discovered or last edited.
Edit User. User who last edited the appliance's information.
Create Date. Date and time the appliance was registered and licensed.

To view the Web Configuration Utility for an appliance, where you can track license data, interfaces, and other device settings, click the Appliance Manager icon (). Use the same login credentials that you used to log into SL1, and close the pop-up window for the Utility when you are done.
If an SL1 appliance is running a different version of SL1 than the Database Server, that appliance is highlighted in the Appliance Manager page. The version number, if known, is listed in the Build column.
For all SL1 appliances, SL1 runs the system status script every 15 minutes. You can click the logs icon () to view the results of the latest system status script.
If you are logging in to the "sl1admin" account on an appliance, you can click the padlock () icon for that appliance to get a one-time password. For more information, see Using the sl1admin Account.
For Database Servers, you can click the gear icon () to access the phpMyAdmin interface for the Database Server. In this interface, you can view all the database tables on the Database Server.
For Data Collectors and Message Collectors, you can click the lightning bolt icon () to manually force the Database Server to send the latest configuration information.

The bomb icon () does not appear for Database Servers that are not configured for High Availability or Disaster Recovery. The bomb icon does not appear for Database Servers that are configured as the primary database in a High Availability or Disaster Recovery configuration.
Click the Save button to save any changes. Click the Save As button to save your changes to a new appliance name.

The Web Configuration Utility

The Web Configuration Utility allows you to configure system-level settings for your appliances. Each appliance includes access to the Web Configuration Utility.

The Web Configuration Utility adds an additional layer of security to SL1 by segregating administrative functions from the rest of the user interface and by exposing system-level settings and diagnostic tools that might otherwise require command-line access to the appliance. The Web Configuration Utility can be accessed only through an HTTPS connection and requires its own administrator-level password.

Perform the following steps to log in to the Web Configuration Utility:

You can log in to the Web Configuration Utility using any web browser supported by SL1. The address of the Web Configuration Utility is in the following format:

https://ip-address-of-appliance:7700
Type the address of the Web Configuration Utility into the address bar of your browser, replacing "ip-address-of-appliance" with the IP address or public-facing fully qualified hostname of the appliance.
You will be prompted to type your username and password. Log in as em7admin with the appropriate password. The default password is em7admin. After logging in, the main Configuration Utility page appears:

For better security, change your Web Configuration Utility credentials. If you leave your Web Configuration Utility credentials as the stock credentials, you greatly increase the risk that your central database could be attacked, or that you could be locked out of the Web Configuration Utility.

In the Configuration Utility, you can license a SL1 appliance, configure interfaces, and edit settings for the SL1 appliance and the Database Server if applicable.

For details on using the Configuration Utility to license a SL1 appliance, see the section on licensing each appliance after installation.
For details on using the Configuration Utility to inform Data Collectors, Message Collectors, and Administration Portals when you change the IP address of a Database Server, see the section on Changing IP Addresses.

Global Settings for Asset Automation

The Asset Automation page (System > Settings > Assets) allows you to define the default behavior for all asset records.

For each standard asset field, you can specify:

Whether the field can be automatically populated by SL1.
Whether the field's value should be automatically updated by SL1.
Whether or not SL1 should generate an event if the field's value changes.

You can define the default behavior for each standard field in the following asset pages:

Asset Properties
Asset Maintenance & Service
Asset Configuration
Asset Licenses
Asset IP Networks
Asset Components

The defined behavior will be applied to every asset record in SL1.

For more details on asset records and enabling automation for asset records, see the Asset Management and Vendors section.

Global Settings for User Logins, Discovery, Data Collection, UI Features, and Expiration Warnings

The Behavior Settings page (System > Settings > Behavior) allows you to define global parameters that affect:

User Logins
Discovery
Data collection
Settings that affect the display and behavior of the user interface
Expiration warnings for asset warranties and SSL certificates

The parameters in the Behavior Settings page affect all pages, devices, and discovery functionality in SL1. For most settings, you can define a one-time, manual override in the affected page. You can also override many of these settings per device. For example, you can define global parameters for nightly discovery in this page, but you can override these settings for a specific device on the Settings tab of the Device Investigator page or the Device Properties page (Devices> Device Manager > wrench icon) in the classic user interface.

To define or edit the settings in the Behavior Settings page:

Go to the Behavior Settings page (System > Settings > Behavior).

On the Behavior Settings page, edit the values in one or more of the following fields:

Interface URL. URL for accessing the user interface. This value should be in URL format and can be up to 64 characters in length. Do not include a trailing forward slash ("/") at the end of the Interface URL. When SL1 generates URLs for tickets or events (for example, in email messages), the trailing forward slash will be automatically included.

Force Secure HTTPS. [Recommended] If enabled, forces users to use HTTPS (secure HTTP) instead of HTTP when they connect to the user interface. This eliminates the exposure of credentials between the user or API caller and the central database. Newly installed SL1 systems running version 11.1 or greater force users to use HTTPS by default.

Password Expiration. Specifies whether or not the password for a user account will expire and if so, when the password will expire. Choices are:

Disabled. Passwords do not expire or are managed externally to SL1.
30 Days. Passwords will expire after 30 days.
60 Days. Passwords will expire after 60 days.
90 Days. Passwords will expire after 90 days.
180 Days. Passwords will expire after 180 days.

Password Reset Interval. The minimum amount of time that must pass before a user can change a password. For example, if the value in this field is 2 Hours, a user can change a password every two hours. This applies to users changing their own passwords and administrators changing other users' passwords. Values range from 1 hour to 24 hours, in increments of one hour.

Password Hash Method. Specifies how user passwords will be encrypted for storage in the ScienceLogic database. You can choose the hashing algorithm that works best for your enterprise. Choices are:

SHA-512. AS of 10.2.0, this is the default value. Previous passwords will use their previous hash method until the password is changed.
Automatic (PHP Password API)

Password Minimum Length. Specifies the minimum number of alphanumeric characters allowed for the password. You can specify any value from 1 to 99. The default value is "8" characters.
User Login Session Timeout. Select the amount of idle time that can pass without any user activity before that user's SL1 session expires. For better security, use a shorter time frame. By default, user sessions expire after 10 minutes of inactivity.
Account Lockout Type. If a user enters incorrect login information multiple times in a row, that user will be locked out of the user interface. In this field, you can select how the lockout will be applied. Choices are:

Lockout by IP Address. All subsequent login attempts from the IP address will be denied once a lockout for that IP address has been identified. Use this option to isolate all access from the remote IP address for any account until a system administrator has validated the lockout and cleared it.
Lockout by Username and IP Address. All subsequent login attempts by this username from the IP address will be denied. This will permit other users from the same IP address to continue to access the system as long as they are not locked out.
Lockout by Username (default). All subsequent login attempts by this username from any IP address will be denied.
Disabled. Lockouts are disabled. This setting can leave your system vulnerable to attacks and as such, it is not recommended.

Account Lockout Attempts. Number of times a user can enter incorrect login information before a lockout occurs. Choices are 1 time through 10 times.

Login Delay. To prevent unauthorized users from using brute-force login attempts, you can set a login delay in this field. After each failed login, SL1 will not allow another attempt for the number of seconds specified in this field. Choices are:

Disabled. SL1 does not enforce a delay between failed logins.
1 Second. After a failed login, SL1 will not allow another attempt for one second.
2 seconds. After a failed login, SL1 will not allow another attempt for two seconds.
4 seconds. After a failed login, SL1 will not allow another attempt for four seconds.
8 seconds. After a failed login, SL1 will not allow another attempt for eight seconds.

Single Instance Login (Admins). Specifies whether more than one instance of a single username can be logged in to the user interface at the same time. Defines the default behavior for users of account type "Administrator". You can specify the following types of behavior:

Disabled. Multiple instances of the same account name can be logged in to the user interface. There are no requirements or limitations on any of the instances. None of the instances will be automatically logged out.
Session can be transferred after. If you select one of these options, the second instance of a user account can log in only after the first instance of the account is inactive. In SL1, an account is considered "inactive" if the user has not performed any tasks or navigated within the user interface. You can specify how long the first instance must be inactive before the second instance can log in. When the second instance successfully logs in to the user interface, the browser where the first instance is logged in will display the following message: "User id 'account name' logged in from a different browser and transferred this session."

NOTE: If this field is set to any value other than disabled, you can still override an earlier instance. If you try to log in to the user interface and there is another instance of the account already logged in to the user interface, the login page will display the following message: "User id 'account name' is already logged in to the system. To transfer the session, check 'Transfer Session' and log in."

If you select the Transfer Session checkbox, this logs the first instance out of the user interface and allows the second instance to log in to the user interface. The browser where the first instance was logged in will display the following message: "User id 'account name' logged in from a different browser and transferred this session."
Other (manual entry). Allows you to enter a custom value, in seconds. When the first instance of a user account is inactive in the user interface for the specified number of seconds, the first instance is logged out and the second instance is allowed.

NOTE: To support single instance login in the current SL1 user interface ("AP2"), you must make the appropriate settings in this field and then perform additional steps. For more information, see the section on Configuring Single Instance Login in AP2.

Single Instance Login (Users). Specifies whether more than one instance of a single username can be logged in to the user interface at the same time. Defines the default behavior for users of account type "User". You can specify the following types of behavior:

Disabled. Multiple instances of the same account name can be logged in to the user interface. There are no requirements or limitations on any of the instances. None of the instances will be automatically logged out.
Session can be transferred after. If you select one of these options, the second instance of a user account can log in only after the first instance of the account is inactive. In SL1, an account is considered "inactive" if the user has not performed any tasks or navigated within the user interface. You can specify how long the first instance must be inactive before the second instance can log in. When the second instance successfully logs in to the user interface, the browser where the first instance is logged in will display the following message: "User id 'account name' logged in from a different browser and transferred this session."

NOTE: If this field is set to any value other than disabled, you can still override an earlier instance. If you try to log in to the user interface and there is another instance of the account already logged in to the user interface, the login page will display the following message: "User id 'account name' is already logged in to the system. To transfer the session, check 'Transfer Session' and log in."
If you select the Transfer Session checkbox, this logs the first instance out of the user interface and allows the second instance to log in to the user interface. The browser where the first instance was logged in will display the following message: "User id 'account name' logged in from a different browser and transferred this session."
Other (manual entry). Allows you to enter a custom value, in seconds. When the first instance of a user account is inactive in the user interface for the specified number of seconds, the first instance is logged out and the second instance is allowed.

NOTE: To support single instance login in the current SL1 user interface ("AP2"), you must make the appropriate settings in this field and then perform additional steps. For more information, see the section on Configuring Single Instance Login in AP2.

Account Lockout Duration. Specifies how long a user will be locked out of the user interface. Choices are 1 hour – 24 hours, in one hour increments. The shorter the duration, the sooner the system is again vulnerable to a potential attack; however, a shorter duration will also allow a user to attempt to log in again without the help of a system administrator.
Lockout Contact Information. This contact information will be displayed when a user is locked out of the user interface. Can be any combination of alphanumeric characters, up to 255 characters in length. This information should allow the user to contact his/her administrator to unlock the account.
Login Header Title. HTML title of the login page. This text will appear at the very top of the browser on the login page.
System Identifier. Unique name for the current SL1 system. Can be up to 128 characters in length. This field is useful for companies or organizations with multiple SL1 systems. If a value is provided in this field, SL1 will include a "system identifier" value in each event generated by the current SL1 system. This allows users to easily determine the source SL1 system associated with the event.
Ping & Poll Timeout (Msec.). This field specifies the number of milliseconds the discovery tool or availability polling will wait for a response after pinging a device. After the specified number of milliseconds have elapsed, the poll will timeout. The choices are between 100 and 5000 milliseconds.
SNMP Poll Timeout (Msec.). This field specifies the number of milliseconds the discovery tool will wait for a response after sending an SNMP query to a device. After the specified number of milliseconds have elapsed, the SNMP poll will timeout. The choices are between 100 and 5000 milliseconds.
SNMP Failure Retries. This field specifies the number of times the discovery tool will try to communicate with a device after a timeout or failure. After that number of times has been met, the discovery tool will not retry unless the user manually restarts the discovery process. The choices are 0–6.
Initially Discovered Interface Poll Rate. This field specifies the frequency with which SL1 will poll newly discovered interfaces. This setting does not affect interfaces that have been previously discovered with a different value in this field or interfaces for which the Frequency field has been manually edited in the Interface Properties page.
DHCP Community Strings (Comma separated). SNMP "read only" community string to use during discovery. This is required only if DHCP servers and devices use a different SNMP community string than other devices in the network. If the community string specified in the Discovery Control Panel page (System > Manage > Classic Discovery) does not work for DHCP devices, SL1 will automatically use the community string specified in this field.
Strip FQDN From Inbound Email Device Name. In Events from Email policies, specifies how SL1 will match the regular expression for device name. Choices are:

Enabled. SL1 will search the text string in the incoming email and match all characters up to the first period that appears in the text string. If multiple devices match the characters up to the first period (for example, my_device.1 and my_device.2), SL1will align the event with the matching device with the highest Device ID.
Disabled. SL1 will search the text string in the incoming email for a match for the device name. The text string must include an exact match to the regular expression (defined in the Events from Email policy), including any text following a period in the device name. If SL1 does not find an exact match in the incoming email, SL1 creates an entry in the system log.

Inbound Email Alert Message. In each event policy, the First Match String and Second Match String fields specify the string or regular expression used to correlate the event with a log message. To trigger an event, the text of a log message must match the value in the First Match String and Second Match String fields in that event's policy. For Events from Email policies, this field specifies whether only the email message body will be written to the device log or whether both the email message subject and email message body will be written to the device log. Choices are:

Email Message Body Only. Only the email message body is written to the device log. The First Match String and Second Match String fields can examine and match only the email message body.
Email Message Subject and Body. Both the email message body and the email message subject are written to the device log. The First Match String and Second Match String fields can examine and match against both the email message body.

NOTE: The global setting Inbound Email Alert Message affects how events are triggered. This field does not affect the Regex Pattern field in the Event from Email policy. The Regex Pattern field in an Event from Email policy specifies which device log to write to.

Event Console Ticket Life Ring Button Behavior. Specifies how the life-ring icon () in the Event Console will behave. Choices are:

Create/View EM7 Ticket. When you click the life-ring icon () for an event in the Event Console, SL1 will display the Ticket Editor page, where you can define a ticket and automatically associate it with the selected event. This is the default behavior.
Create/View External Ticket. If an external ticket is aligned with an event, when you click the life-ring icon () for that event (from the Event Console), SL1 spawns a new window and displays the external ticket (as specified in the force_ticket_uri field). If an external ticket is not yet aligned with an event, when you click the life-ring icon () for that event, SL1 sets a "request" flag for the ticket and displays an acknowledgment that a new ticket has been requested. You can then use the "request" in run book logic, to create the ticket on the external system.

If you select Create/View External Ticket in the Event Console Ticket Life Ring Button Behavior field, you can no longer create tickets from the Event Console.

Automatic Ticketing Emails. Specifies whether ticket watchers will automatically receive email notification when a ticket is created or changes status. Choices are:

Enabled. This is the default value. When you select this option, SL1 automatically sends email notifications to all watchers when a ticket is created, assigned, or updated.
Disabled. When you select this option, SL1 does not automatically send email notifications to all watchers when a ticket is created, assigned, or updated.

Prevent Browser Saved Credentials. This checkbox specifies whether SL1 will allow the browser to cache login credentials and perform auto-complete in the login page. By default, the user interface will allow browsers to cache login credentials. Choices are:

Selected. The user interface will not allow browsers to cache credentials and use auto-complete in the login page. Use this setting to comply with PCI DSS and other security protocols.
Not Selected. This is the default setting. The user interface will allow browsers to cache credentials and use auto-complete in the login page. The implementation of this functionality varies between browsers.

Prevent Loading Interface in External Frames. If you select this checkbox, other pages cannot be loaded in external frames in the same browser session that includes SL1. This is a security measure, to prevent click-jacking attacks.
Hide Perpetual License Count. Specifies whether to display the device count graph in the System Usage page (System > Monitor > System Usage). The default behavior is to hide the graph in the System Usage page. Users might find this graph useful to troubleshoot licensing issues. For a description of the System Usage page, see the Monitoring Overall System Usage and Statistics section.
Hide "New" button on the Ticket Editor. If you select this checkbox, the Ticket Editor page will not display the New button. This field is unselected by default.
Enable Unique Asset Tag to Organization Constraint. Select this option if you want to prevent an asset from being moved to another organization if the new organization is already aligned to an asset with the same Asset Tag. Do not select this option if you want to allow assets with the same Asset Tags in the same organization. This field is selected by default.
Display Previous Login In Footer. If you select this checkbox, the user interface will display information about the last successful login to the user interface and the last failed login (if applicable). The user interface will display the following in the lower right of the page:
Previous Login: yyyy-mm-dd hh-mm-ssfrom user's IP address.
Failed Login: yyyy-mm-dd hh-mm-ssfrom user's IP address.

Ignore trap agent-addr varbind. If you select this checkbox, SL1 will align incoming SNMP trap messages with the forwarding device (last hop) instead of searching for the IP address of the originator of the trap.

Enable Selective PowerPack Field Protection. If you select this checkbox, the following fields will not be updated when you update a PowerPack:

Event Policy > Operational State
Event Policy > Event Severity
Event Policy > Event Message
Event Policy > Occurrence Count
Event Policy > Occurrence Time
Event Policy > Expiry Delay
Event Policy > Detection Weight
Event Policy > External Event ID
Event Policy > External Category
Event Policy > Use multi-match
Event Policy > Use message-match
Event Policy > Topology Suppression
Dynamic Application > Properties > Operational State
Dynamic Application > Properties > Poll Frequency
Dynamic Application > Properties > Disable Data Rollup
Dynamic Application > Collection > Custom Attribute
Dynamic Application > Collection > Asset / Formlink
Dynamic Application > Collection > Change Alerting
Dynamic Application > Collection > Hide Object
Dynamic Application > Presentation > Active State
Dynamic Application > Threshold > Override Threshold Value
Dynamic Application > Threshold > Numeric Range: High
Dynamic Application > Threshold > Numeric Range: Low
Dynamic Application > Threshold > Threshold Value
Device Class > Device Dashboard

Hide "Create a Ticket" in Toolbox menu. If you select this checkbox, the Toolbox menu (three stacked horizontal lines in the upper-left corner in the classic user interface) will not display the Create a Ticket option. This field is unselected by default.
Hide "other" filesystem types. If you select this checkbox, file systems of type "other" (which includes XFS file systems) will not be discovered and monitored. This checkbox is selected by default.
Enable CDP Topology. If selected, SL1 will use Cisco Discovery Protocol (CDP) for each device that supports CDP. SL1 will then generate topology maps from the discovered CDP relationships.

CDP is a proprietary protocol developed by Cisco and is not supported by all network hardware. If your network includes both CDP enabled and non-CDP network switches and routers, the topology data reported by the CDP enabled devices might not be accurate. In SL1, if a conflict exists between the collected CDP topology data and the collected layer-2 topology data, the CDP topology data takes precedence. In some cases, the ScienceLogic layer-2 data might be more accurate. Therefore, if your network includes both CDP enabled and non-CDP network switches and routers, you might want to disable CDP topology collection. For details, see the section on CDP Maps.

Enable LLDP Topology. If selected, SL1 will use Link Layer Discovery Protocol (LLDP) for each device that supports LLDP. SL1 will then generate topology maps from the discovered LLDP relationships.
Enable Community String Indexing (VLAN Topology). If selected, SL1 will perform discovery of VLANs during topology collection. By default, this option is not selected because the SNMP requests used to discover VLANs might cause some types of hardware to erroneously reboot.
Default Country. Specifies the country that will be selected by default in each page where the user specifies a country. The user can override this default value in each page.
System Timezone. Specifies the default timezone for SL1. In each page where the user can select a timezone, this value will be selected by default. The user can override this default value in each page. SL1 also uses this default value to perform timezone conversions when no user timezone setting is available. For example, if SL1 sends an email to an address not associated with a user, any timestamps contained in the email will use the value from the System Timezone field. You can select from a list of all timezones. The default value is "UTC".
NFS Detection Disable. If selected, this checkbox prevents SL1 from monitoring and reporting on NFS "shared" file systems. SL1 will monitor and report only on local file systems.
Port Polling Type. Specifies how SL1 should poll devices to discover open ports. The choices are:

Half Open. Uses a faster TCP/IP connection method and does not appear on the device's logs.
Full Connect. Uses the standard TCP/IP connection to detect open ports.

Initial Discovery Scan Level. Specifies the data to be gathered during the initial discovery session. The options are:

0. Model Device Only. Discover if device is up and running and if so, discover device's make and model.
1. Discover Dynamic Apps. Discovery tool will search for Dynamic Applications associated with the device. Discovery will also perform 0. Model Device Only discovery.
2. Initial Population of Apps. Discovery tool will retrieve subset of data from Dynamic Applications, to save time. Discovery tool will later retrieve full sets of data from each Dynamic Application. Discovery tool will also perform 1. Discover Dynamic Apps and 0. Model Device Only.
3. Discover SSL Certificates. Discovery tool will search for SSL certificates and retrieve SSL data. Discovery tool will also perform 2. Initial Population of Apps, 1. Discover Dynamic Apps, and 0. Model Device Only.
4. Discover Open Ports. Discovery tool will search for open ports. Discovery tool will also perform 3. Discover SSL Certificates, 2. Initial Population of Apps, 1. Discover Dynamic Apps, and 0. Model Device Only. If your system includes a firewall and you select option 4: Discover Open Ports, discovery may be blocked and/or may be taxing to your network.
5. Advanced Port Discovery. Discovery tool will search for open ports, using a faster TCP/IP connection method. Discovery tool will also perform 3. Discover SSL Certificates, 2. Initial Population of Apps, 1. Discover Dynamic Apps, and 0. Model Device Only. If your system includes a firewall and you select option 5: Advanced Port Discovery, some auto-discovered devices may remain in a pending state for some time after discovery. These devices will achieve a healthy status, but this might take several hours.

Rediscovery Scan Level (Nightly). Specifies the data to be gathered/updated each day during the nightly discovery process. The nightly discovery process will find any changes to previously discovered devices. The Rediscovery Scan Level (Nightly) field contains the same options as the Initial Discovery Scan Level field.
Discovery Scan Throttle. Specifies the amount of time a discovery process should pause between each IP address in a discovery session. Pausing discovery processes between IP addresses spreads the amount of network traffic generated by discovery over a longer period of time. The Discovery Scan Throttle setting does not affect nightly auto discovery. The choices are:

Disabled. Discovery processes will not pause.
1000 Msec to 10000 Msec. A discovery process will pause for a random amount of time between half the selected value and the selected value.

Port Scan All IPs. Specifies whether SL1 should scan all IP addresses on a device for open ports. The Port Scan All IPs setting affects initial discovery, nightly auto discovery, and re-discovery.The choices are:

0. Disabled. SL1 will scan only the Admin Primary IP address (the IP address SL1 uses to communicate with the device) for open ports.
1. Enabled. SL1 will scan all discovered IP addresses for open ports.

Port Scan Timeout. Length of time, in milliseconds, after which SL1 should stop trying to scan an IP address for open ports and begin scanning the next IP address (if applicable). The Port Scan Timeout setting affects initial discovery, nightly auto discovery, and re-discovery. Choices are between 60,000 and 1,800,000 milliseconds.

Restart Windows Services (Agent required). Specifies whether SL1 should automatically restart failed Windows services that have been defined on the device with a startup type of "automatic". To use this feature, the managed device must be running the agent SNMP Informant, WMI Edition. For assistance or information on purchasing and installing this agent, please contact ScienceLogic. Users must also supply a value in the SNMP Write field in the Device Properties page for the device. The choices are:

0. Disabled. SL1 will not automatically restart failed Windows services that have been defined on the device with a startup type of "automatic".
1. Enabled. SL1 will automatically restart failed Windows services that have been defined on the device with a startup type of "automatic".

Hostname Precedence. Specifies which name SL1 will use for each discovered device. Choices are:

SNMP System Name. Use the device name specified in the device's SNMP System MIB. If SNMP System Name is selected and SL1 cannot find an SNMP name for the device, SL1 will assign the name returned by the DNS Reverse Lookup. If SL1 cannot find a DNS Reverse Lookup name for the device, SL1 will use the device's Admin Primary IP address as the device name in SL1.
DNS Reverse Lookup. Use the device name specified in the device's reverse-lookup record.

Event Interface Name Format. Specifies the format of the network interface name that you want to appear in events. If you selected Interface Alias for the deprecated Interface Name Precedence field in a previous release of SL1, the format for existing interfaces is set to {alias}. If you selected Interface Name for the deprecated Interface Name Precedence field in a previous release of SL1, the format for existing interfaces is set to {name}. The default format is {name}. You can use a combination of string text and the following tokens to define the interface name format for events, such as string_{name}, string_{alias}, {name}{alias}, or {ifdesc}:

{alias}
{name}
{state}
{ifdescr}
{if_id}
{did}
{ifindex}
{ifphysaddress}
{iftype}
{ifspeed}
{ifhighspeed}
{ifoperstatus}
{ifadminstatus}

DNS Hostnames. If SL1 will use the DNS Reverse Lookup name as the device name (see the description of the field Hostname Precedence), this field specifies whether SL1 will use the fully-qualified domain name or only the hostname for each discovered device. Choices are:

Strip Device Name (Hostname). SL1 will use only the device name as the DNS hostname for each device.
Use Full Domain Name (FQDN). SL1 will use the fully-qualified domain name as the device name for each device.

Event Clearing Mode. Describes how clearing an event will affect correlated events. Choices are:

Clear Selected Only. Clear only the selected events. If a parent event is cleared, the previously suppressed child events will appear in the Event Console.
Clear All in Group. When parent event is cleared, all child events correlated with parent event will be cleared. This is the default behavior.

Maintenance Minimum Severity. Specifies the minimum severity required for an event to be suppressed during device maintenance and user maintenance for devices. The default value is Healthy, which causes all events to be suppressed. Choices are Healthy, Notice, Minor, Major, or Critical.
Patch Maintenance Minimum Severity. If you schedule Device Maintenance and have defined a Patch Window within the larger maintenance interval, this field allows you to specify the event severity that will trigger the beginning of the Patch Window. The first event that both matches the severity in this field and occurs within the larger maintenance window triggers the start of the Patch Window. Choices are Healthy, Notice, Minor, Major, or Critical.
SSL Certificate Expiry Soon. Specifies, in number of days, when SL1 should generate an event for an SSL Certificate that is about to expire. The choices range from 1 day to 9 months.
SSL Certificate Expiry Imminent. Specifies, in number of days, when SL1 should generate a more urgent event for an SSL Certificate that is about to expire. The choices range from 1 day to 9 months.
Asset Warranty Expiry. Specifies, in number of days, when SL1 should generate an event for an asset warranty that is about to expire. The choices range from 1 day to 9 months.
Domain Name Expiry. Specifies, in number of days, when SL1 should generate an event for a domain's registration that is about to expire. The choices range from 1 day to 9 months.
Validate Phone Number. Specifies whether or not phone numbers entered into the user interface must be in US format. Choices are:

Disabled. Phone numbers are not required to be in US format.
Enabled. Phone numbers must be in US format.

Dashboard Maximum Series Count Per Widget. This field allows you to select the maximum number of time-series lines that can appear in a single Multi-series Performance widget. Choices are 8–25. Increasing this setting might cause longer load times in the Dashboards tab page.
Responder API Base URL. This field lets you update the Responder API Base URL, which is required if you want to align PowerShell Dynamic Applications to the agent. In SL1 version 11.2.0 and later, SL1 completes this field for you.
Component Device Map Update Mode. This field specifies how SL1 rebuilds relationships between component devices that are created by Dynamic Applications (DCM-R). Choices are:

[Periodic]. (Default). A rebuild of the component device map occurs at a set interval, which is defined in the DCM+R Rebuild process (System > Settings > Processes). By default, the process runs every five minutes. Note that the Operating State for the DCM+R Rebuild process must be set to "Enabled" before periodic component device map updates will work. For more information, see Viewing Information About ScienceLogic Processes.
DCM-R Triggers. A rebuild of the component device map occurs immediately after topology changes are registered.

Setting the Component Device Map Update Mode to "DCM-R Triggers" might impact your system if your environment has large topology trees or if the environment experiences frequent simultaneous topology changes.

Enable CBQoS Collection. If selected, SL1 will collect configuration data about Class-Based Quality-of-Service (CBQoS) from interfaces that are configured for CBQoS. If selected, you can enable collection of CBQoS metrics per-interface. The collected CBQoS metrics are displayed in Device Performance reports associated with the device that contains those interfaces. This setting is disabled by default. (For more information about Device Performance reports, see the section on Viewing Performance Data.)
Enable Variable Rate Interface Counters. If selected, enables more accurate collection of data from interfaces. If enabled, when SL1 retrieves data from an interface, that data is stored in the ScienceLogic database along with the timestamp associated with the exact collection time. Before normalization occurs, SL1 applies an interpolation function that spaces the data at regular time intervals. For example, suppose you have specified that SL1 should collect interface data every five minutes. However, due to network traffic across the Data Collectors, SL1 might collect data from an interface at 13:01 and then 13:05. Because the ScienceLogic normalization process expects data that has been collected every five minutes, SL1 first applies an interpolation to the data to prepare the data for normalization. With Enable Variable Rate Interface Counters enabled, graphing interpolates between two collected data points without a limit of the distance between those data points. However, performance graphs will not display interpolation between two points where there is no supporting collected data, or "data gap", for a collection time when this feature is disabled.
Enable Concurrent SNMP Collection. If selected, enables Concurrent SNMP Collection for all SNMP collection. Concurrent SNMP Collection allows multiple collection tasks to run at the same time with a reduced load on Data Collectors. Concurrent SNMP Collection also prevents missed polls and data gaps because collection will execute more quickly. For details see the section on SNMP concurrent collection.
Enable Concurrent Network Interface Collection. If selected, enables asynchronous concurrent SNMP collection for all network interfaces. This provides better scalability for large networks by allowing multiple collection tasks to run at the same time with a reduced load on Data Collectors.
New UI Default. Starting with SL1 11.1.0, the new SL1 user interface ("AP2") is the default user interface. If you want to make the classic user interface the default interface, de-select this option. If your 11.1.0 SL1 system was installing using an ISO, the SL1 user interface is set as the default, but if your SL1 system was upgraded with a patch, the classic user interface will still be set as the default user interface.
Include PowerPack Sensitive Fields. If selected, lets you include sensitive fields when sharing a PowerPack. These sensitive fields include passwords and SSH keys.
Prefer Global Device Summary Dashboard Over Category/Class. If you select this checkbox, the global default device dashboard will be displayed as the default in the Device Summary page instead of the device dashboard assigned to the device category or device class of the device. For more information about device dashboards, see the section on Device Dashboards.
Enhanced OID Translation. If selected, ensures that varbind OIDs that use multi-dimensional indexes are translated correctly. The symbolic translation of the known portion of the OID is included in the log message associated with the trap. Enabling the Enhanced OID Translation option might affect performance on large environments with a large number of traps.
Enable Concurrent PowerShell Collection. If selected, enables concurrent PowerShell collection for all PowerShell collection, which allows multiple collection tasks to run at the same time with a reduced load on Data Collectors.
Report Size Estimation. If selected, enables the Row Count Estimate field for custom reports on the Run Report page (Reports > Run Report). This field provides an estimate of the number of rows that will appear in the report before SL1 generates the report. The estimate changes based on the selections you make for the report. You can use this field to manage the size of the generated report by adding or removing items from the report as needed.

Click the Save button to save changes in this page.

Configuring Single Instance Login for AP2

The Single Instance Login fields on the Behavior Settings page enable you to specify whether more than one instance of a single username can be logged in to the user interface at the same time.

In the classic SL1 user interface, you can configure single instance login using just those fields. However, for the current SL1 user interface ("AP2"), you must complete several additional steps.

To configure single instance login in AP2:

Go to the Behavior Settings page (System > Settings > Behavior).
Make the appropriate selections in the Single Instance Login (Admins) and Single Instance Login (Users) fields, and then click Save.
Either go to the console of the SL1 Database Server or use SSH to access the SL1 All-In-One Appliance.
Log in as user em7admin.
At the command line, open the nextui.env file in the vi editor:

sudo vi /opt/em7/nextui/nextui.en

Un-set the environment variable AUTH_CACHE=300000 by adding # as a prefix to that line.
Save and exit the nextui.env file.
Restart the nextui server:

sudo systemctl restart nextui

Global Settings for Data Retention

The Data Retention Settings page (System > Settings > Data Retention) allows you to define parameters for log and data retention.

These settings apply to all logs and all collected data. However, you can override these system settings on a case-by-case basis. For example, you can define data-retention thresholds for a device in the Device Thresholds page. The settings you define for the specific device override the settings in the Data Retention Settings page.

For details on data roll-up and data normalization, see Normalization and Roll-Up of Performance Data.

From the Data Retention Settings page, you can edit how long the platform stores log entries and collected data. To edit the settings for data retention:

Go to the Data Retention Settings page (System > Settings > Data Retention).

On the Data Retention Settings page, you can drag sliders to change the value of each field or manually enter values in the fields to the right of the sliders. You can edit the value for one or more of the following fields:

Audit Logs. Number of months to retain log entries in the Audit Logs page (System > Monitor > Audit Logs). Log entries that are older than the specified number of months are automatically deleted. The default value is 3 months.

Event Logs. Number of days to retain event logs. Event history data is used to generate the Event Overview page (System > Monitor > Event Overview). Log entries that are older than the specified number of months are automatically deleted. The default value is 3 months.
Access Logs. Number of months to retain log entries in the Access Sessions page (System > Monitor > Access Logs). Log entries that are older than the specified number of months are automatically deleted. The default value is 12 months.
System Logs. Number of days to retain log entries in the System Logs page (System > Monitor > System Logs). Log entries that are older than the specified number of days are automatically deleted. The default value is 31 days.
Collection Unit Data Buffer. Number of days each Data Collector and Message Collector should store collected data. Choices are 1-10 days. Data that has been retrieved by the Database Server will be stored on the Data Collector(s) and optional Message Collector(s) for the specified number of days and then automatically deleted from the server(s). This setting does not apply to All-In-One Appliances. The default value is 2 days.
Ad-hoc and Scheduled Reports. Number of days SL1 will retain Quick Reports and Scheduled Reports in the Scheduled Report Archive page (Scheduled Job > Report Archive > Archived Job button). Possible values are 0 - 365, in days. If you use the default value of 0, SL1 will remove files older than 30 days from the populated directory: /opt/em7/gui/ap/www/em7/libs/od_templates/populated.
Raw Performance Data. Number of days to retain performance data collected from devices. This setting applies to all performance data types, except for bandwidth data. Performance data that is older than the specified number of days is automatically deleted. This is the default system-wide value. The value in the Device Thresholds page for each device can override this value. The default value is 7 days.
Hourly Rollup Performance Data. Number of days to retain hourly normalized performance data for devices. This setting applies to all performance data types, except for bandwidth data. Hourly normalized performance data that is older than the specified number of days is automatically deleted. This is the default system-wide value. The value in the Device Thresholds page for each device can override this value. The default value is 90 days.
Daily Rollup Performance Data. Number of months to retain daily normalized performance data for devices. This setting applies to all performance data types, except for bandwidth data. Daily normalized performance data that is older than the specified number of months is automatically deleted. This is the default system-wide value. The value in the Device Thresholds page for each device can override this value. The default value is 24 months.
Configuration Data. Number of days to retain data from Dynamic Applications of type "configuration". The value in the Device Thresholds page for each device can override this value. The default value is 7 days.
Journal Data. Number of days to retain collected data from Dynamic Applications of type "journal". The value in the Device Thresholds page for each device can override this value. The default value is 60 days.
Bandwidth Data. Number of days to retain bandwidth data and CBQoS data collected from each interface on a device. Bandwidth data that is older than the specified number of days is automatically deleted. The value in the Device Thresholds page for each device can override this value. The default value is 31 days.

Hourly Rollup Bandwidth Data. Number of days to retain hourly normalized data and hourly normalized CBQoS data for each interface on a device. Hourly normalized data that is older than the specified number of days is automatically deleted. The value in the Device Thresholds page for each device can override this value. The default value is 90 days.

Daily Rollup Bandwidth Data. Number of months to retain daily normalized data and daily normalized CBQoS data for each interface on a device. Daily normalized data that is older than the specified number of months is automatically deleted. The value in the Device Thresholds page for each device can override this value. The default value is 24 months.
Bandwidth Billing Data. Number of months to retain data collected by each bandwidth billing policy. Bandwidth billing data that is older than the specified number of months is automatically deleted. The default value is 24 months.
Device Logs Age. Number of days to retain each device log. Log records that are older than the specified number of days are automatically deleted. The value in the Device Thresholds page for each device can override this value. The default value is 90 days.
Device Logs Max. Maximum number of records to store in each device log. When this number is exceeded, the oldest entries will be deleted. The value in the Device Thresholds page for each device can override this value. The default value is 10,000 records.
Raw ITSM Data. Before the value for a metric in an IT Service policy is calculated, a copy of all the device data that will be aggregated is saved. This setting is the number of days to retain the un-aggregated copies of device data associated with each IT Service. The default value is 31 days.
ITSM Service Metrics Data. Number of days to retain values for metrics in IT Service policies. The default value is 30 days, with a maximum of 30 days.
Hourly Rollup ITSM Service Metrics Data. Number of days to retain hourly normalized values for metrics in IT Service policies. The default value is 90 days, with a maximum of 90 days.
Daily Rollup ITSM Service Metrics Data. Number of months to retain daily normalized values for metrics in IT Service policies. The default value is 12 months.
ITSM Key Metrics Data. Number of days to retain values for key metrics in IT Service policies (Health, Availability, and Risk). The default value is 30 days, with a maximum of 30 days.
Hourly Rollup ITSM Key Metrics Data. Number of days to retain hourly normalized values for key metrics in IT Service policies (Health, Availability, and Risk). The default value is 90 days, with a maximum of 180 days.
Daily Rollup ITSM Key Metrics Data. Number of months to retain daily normalized values for key metrics in IT Service policies (Health, Availability, and Risk). The default value is 24 months.
Ports Data Retention. Specifies the number of days after which expired port data will be marked for deletion during the hourly maintenance process. The default value is 730 days.
Services Data Retention. Specifies the number of days after which expired services data will be marked for deletion during the hourly maintenance process. The default value is 24 hours.
Filesystems Data Retention. Specifies the number of hours after which expired filesystems data will be marked for deletion during the hourly maintenance process. The default value is 24 hours.
Subscriber Device Configuration Data. For users with a subscriber license. Number of months to retain the files and database tables that contain configuration information for a device. Default value is 6 months.
Subscriber Device Usage Data. For users with a subscriber license. Number of months to retain the files and database tables that contain usage information for a device. Default value is 6 months.
Subscriber System Configuration Data. For users with a subscriber license. Number of months to retain the files and database tables that contain configuration information for the SL1 system. Default value is 3 months.
Subscriber System Usage Data. For users with a subscriber license. Number of months to retain the files and database tables that contain usage information for the SL1 system. Default value is 3 months.
Subscriber Device Type Data. For users with a subscriber license. Number of months to retain the files and database tables that map each device to a device category, as per your subscriber license. Default value is 3 months.
Subscriber Daily Delivery Data. For users with a subscriber license. Number of months to retain the "crunched" license usage data that is calculated each day using the Subscriber Device Configuration Data, Subscriber System Configuration Data, Subscriber System Usage Data, and Subscriber Device Type Data. SL1 will not prune data that has not yet been delivered to the ScienceLogic Licensing and Billing server. Default value is 3 months.

Click the Save button to save any changes to the data-retention settings.

NOTE: In SL1, normalized data does not include polling sessions that were missed or skipped. So for normalized data, null values are not included when calculating maximum values, minimum values, or average values.

You might want to retain normalized data for longer periods of time and non-normalized data for shorter periods of time. This allows you to save space and still create historical reports.

Normalization and Roll-Up of Performance Data

Normalization and roll-up are the ways in which SL1 processes collected performance data for display and storage. Note the following important distinctions:

Raw data is the data exactly as it was collected from a device or application.
Normalized and rolled up data is data for which SL1 has calculated summary statistics (sample size, count, maximum value, minimum value, mean value, average value, sum, and standard deviation) over a period of time.

Collection of Raw Data

Collector	Collected Data and Intervals
Dynamic Applications	Collects raw performance data from a device at the following intervals: 1 minute 2 minutes 3 minutes 5 minutes 10 minutes 15 minutes 30 minutes 1 hour 2 hours 6 hours 12 hours 24 hours For performance Dynamic Applications, you specify this interval in the Poll Frequency field, in the Properties Editor page (System > Manage > Applications > Create or use the ).
IT Services	IT Service policies can generate raw performance data for an IT service by aggregating raw performance data from devices in the policy at the following intervals: 1 minute 2 minutes 3 minutes 5 minutes 10 minutes 15 minutes 30 minutes 1 hour 2 hours 6 hours 12 hours 24 hours You can specify the interval at which the IT Service policy collects and aggregates data in the Aggregation Frequency field, in the IT Service Editor page (Registry > IT Services > IT Service Manager > Create or use the ).
Bandwidth	Collects raw bandwidth data from a network interface at the following intervals: 1 minute 5 minutes 10 minutes 15 minutes 30 minutes 60 minutes 120 minutes You can specify the frequency at which SL1 collects raw data for a specific interface by selecting the interval in the Frequency field, in the Interface Properties page (Registry > Networks > Interfaces > interface wrench icon and select the for the given interface).
Additional Performance Data	SL1 collects additional raw performance data about availability, latency, file systems, and statistics generated by monitoring policies for DNS availability, Email round-trip time, system processes, system services, port availability, web-content availability, and SOAP/XML transactions. By default, SL1 collects this data every 5 minutes.

Data Normalization and Rollup

SL1 rolls up performance data so that reports with a larger timespan do not become difficult to view and to save storage space in the database. When SL1 rolls up data, SL1 groups data into larger sets and calculates the average value for the larger set.

SL1 supports two types of rollup:

Hourly. Groups and averages data that is collected at intervals of 60 minutes or less. SL1 rolls up data and calculates an average hourly value for each metric. Hourly samples include samples from the top of the hour to the end of the hour. For example, for an hourly rollup of data collected at 1 minute intervals between 1:00 and 2:00, the first data point would be the one collected at 01:00:00 and the last would end at 01:59:00.
Daily. Daily rollup groups and averages all collected data. SL1 rolls up data and calculates an average daily value for each metric. Daily samples include samples from the beginning of the day until the end of the day. For example, for a daily rollup of data collected at 1 minute intervals, the first data point would be the one collected at 00:00:00 and the last data point would the one collected at 23:59:00.

SL1 rolls up raw performance data as follows:

Frequency of Raw Collection	Rollup
Every 1 minute	60 minutes, 24 hours
Every 2 minutes	60 minutes, 24 hours
Every 3 minutes	60 minutes, 24 hours
Every 5 minutes	60 minutes, 24 hours
Every 10 minutes	60 minutes, 24 hours
Every 15 minutes	60 minutes, 24 hours
Every 30 minutes	60 minutes, 24 hours
Every 60 minutes	60 minutes, 24 hours
Every 120 or longer	24 hours

Before SL1 normalizes date, SL1 transforms the data. To transform the data, SL1 does the following:

For bandwidth data and data from Dynamic Applications of type "Performance", SL1 derives rates from counter metrics. The rate from counter metrics are expressed in units-per-polling_interval. For example, rates for 5 minute collections are expressed as units-per-5-minutes.
For data from Dynamic Applications of type "Performance", SL1 evaluates presentation formulas. Counter metrics are first transformed into rates before evaluation.

During the data transform steps, SL1 does not directly rollup the raw data in the database tables.

When SL1 rolls up data, SL1 must normalize that data, as follows:

As a new piece of data is collected by SL1, the hourly normalization and daily normalization is calculated. SL1 does not wait for the end of an hour or the end of a day to calculate the hourly and daily normalization.

Groups and orders the data
Determines the sample size
Calculates the count
Determines the maximum value
Determines the minimum value
Calculates the mean value
Calculates the average value
Calculates the sum
Determines the standard deviation

In SL1, normalized data does not include polling sessions that were missed or skipped. For normalized data, null values are not included when calculating sample size, maximum values, minimum values, or average values.

Example

Suppose that every five minutes, SL1 collects data about file system usage on the device named my_device. As each raw data point is collected, SL1 normalizes and rolls up the collected data for file system usage for my_device. SL1 does the following:

Apply any necessary data transforms (as discussed in the previous section).
Repeat the following for both hourly normalization and daily normalization:
1. If this is the first data point for an hourly normalization or a daily normalization, insert summary statistics for that one data point
  1. Sample size = 1
  2. Average = value of new data point
  3. Max = value of new data point
  4. Min = value of new data point
  5. Sum = value of new data point
  6. Standard Deviation = 0
2. For all subsequent data points for an hourly normalization or a daily normalization, update the summary statistics of the existing rollup bucket
If there no gaps in collection, the summary statistics for hourly normalization will represent 12 data points and the summary statistics for daily normalization will represent 288 data points.

Storage of Raw and Rolled Up Data

There are two ways you can define how long SL1 should store raw data and rolled up and normalized data:

You can define system-wide, default settings in the Data Retention Settings page (System > Settings > Data Retention). These settings apply to all collected data. However, you can override these system settings in the Device Thresholds page (Registry > Devices > Device Manager > wrench icon > Thresholds).
For IT Service policies, aggregated device data is saved to a new database table specifically for the IT service policy. For each IT Service policy, data is normalized and rolled up. You define the data retention settings for an individual IT Service policy in the IT Service Editor page (Registry > IT Services > IT Service Manager > Create or ). These settings override the data retention settings in the Data Retention Settings page (System > Settings > Data Retention).

Global Settings for Inbound Email and Outbound Email

The Email Settings page (System > Settings > Email) allows you to define how SL1 will send and receive email. SL1 automatically sends email when tickets are updated, when automation actions are triggered, and to monitor email round-trip time. Email can be sent to the platform to create tickets and/or events.

From the Email Settings page, you can edit the global email parameters. To do so:

Go to the Email Settings page (System > Settings > Email).
In the Email Settings page, you can edit the value for one or more of the following fields:

Authorized Email Domains. One or more SMTP domains that will be used by SL1. SL1 will use these domains to receive incoming email. This list of domains should include:

All domains used for loopback addresses in email round-trip monitoring policies.
All domains used to generate tickets from emails.
All domains used to receive event messages from third-party monitoring systems.
Each entry in this field must be a fully-qualified email domain and cannot exceed 64 characters. If you include a list of domains, separate the list with commas.
Each domain in this field must be managed by the Database Server. This means that a DNS MX record must already exist or be created for each domain specified in this field. Each DNS MX record must map the domain to the Database Server. When creating the DNS MX record, use the fully-qualified name of the Database Server as the name of the email server.

System From Email Address. The email address from which SL1 will send all outbound email.

Some outbound email servers, such as Gmail, might overwrite the System From Email Address value and instead use the email address of the authenticated user.

Email Formal Name. Name that will appear in the "from" field in email messages sent from SL1. This value can be any alphanumeric value, up to 64 characters in length.
Email Gateway. IP address or fully-qualified name of SL1's SMTP Relay server. If SL1 is to send outgoing messages, this field must be defined. Examples of when SL1 sends outgoing email messages are:

Automatically in response to Tickets from Email policies.
Automatically in response to changes in a ticket (ticket is assigned, edited, or resolved).
Automatically based on Ticket Escalation policies.
Automatically when executing Email Round-Trip Monitoring policies.
Automatically when executing Run Book policies that include email actions.
Automatically based on Report Jobs policies.
Manually, when a user selects the Send Message page from the ticket panel pages.

Each Database Server and All-In-One Appliance includes a built-in SMTP Relay server. The fully-qualified name of SL1 SMTP Relay server is the same as the fully-qualified name of the Database Server or All-In-One Appliance.

If SL1 cannot use its built-in SMTP relay server to route email messages directly to their destination server (for example, due to firewall rules or DNS limitations), SL1 can use another relay server. You can specify the IP address or fully-qualified name of the relay server in this field. Make sure you have configured your network to allow the Database Server or All-In-One Appliance to access this SMTP Relay server.

The Email Gateway field must be configured to use the appropriate port number to use, which is designated by a preceding colon. When no port number is specified, SL1 uses the default SMTP port (25).

Email Gateway Alt. IP address or fully-qualified name of the secondary SMTP Relay server. If the SMTP Relay server specified in the previous field fails or is unavailable, SL1 will use the secondary SMTP Relay server. Make sure you have configured your network to allow the Database Server or All-In-One Appliance to access this SMTP Relay server.
Escalation Notify Subject. Default "Subject" text in emails generated by Ticket Escalation policies. This field can include any combination of variables and text. The field can include up to 64 characters, including one or more variables:

The Escalation Notify Subject field can include one or more of the following variables:

Variable	Source	Description
%1 (one)	Event	Entity type.
%2	Event	Sub-entity type.
%3	Event Policy	Event policy ID.
%4	Event	Text string of the user name that cleared the event.
%5	Event	Timestamp of when event was deleted.
%6	Event	Timestamp for event becoming active.
%7	Event	Event severity (1-5), for compatibility with previous versions of the platform. 1=critical, 2=major, 3=minor, 4=notify, 5=healthy.
%A	Account	Username.
%a	Entity	IP address.
%B	Organization	Organization billing ID.
%b	Organization	Impacted organization.
%C	Organization	Organization CRM ID.
%c	Event	Event counter.
%D	Event	Timestamp of first event occurrence.
%d	Event	Timestamp of last event occurrence.
%E	Event Policy	External ID from event policy.
%e	Event	Event ID.
%F	Dynamic Alert	Dynamic Application alert id.
%f	Event Policy	Specifies whether event is stateful, that is, has an associated event that will clear the current event. 1 (one) = stateful; 0 (zero) = not stateful.
%G	Event Policy	Event Category.
%g	Asset	Asset serial.
%H	Event	URL link to event.
%h	Asset	Device ID associated with the asset.
%I (uppercase "eye")	Dynamic Alert	Table index for a Dynamic Application.
%i (lowercase "eye")	Asset	Asset Location.
%7	Ticket	Ticket subject.
%K	Asset	Asset Floor.
%k	Asset	Asset Room.
%M	Event	Event message.
%m	Automation	Automation policy note.
%N	Action	Automation action name.
%n	Automation	Automation policy name.
%O (uppercase "oh")	Organization	Organization name.
%o (lowercase "oh")	Organization	Organization ID.
%P	Asset	Asset plate.
%p	Asset	Asset panel.
%Q	Asset	Asset punch.
%q	Asset	Asset zone.
%R	Event Policy	Event policy cause/action text.
%r	System	Unique ID / name for the current SL1 system.
%S	Event	Severity (Healthy - Critical).
%s	Event	Severity (0 - 4). 0=healthy, 1=notify, 2=minor, 3=major, 4=critical.
%T	Dynamic Alert	Dynamic Application alert threshold value.
%t	Ticket	Ticket ID.
%U	Asset	Asset rack.
%u	Asset	Asset shelf.
%V	Dynamic Alert	Dynamic Application alert result value.
%v	Asset	Asset tag.
%W	Asset	Asset make.
%w	Asset	Asset model.
%X	Event	Entity name.
%x	Event	Entity ID.
%Y	Event	Sub-entity name.
%y	Event	Sub-entity ID.
%Z	Event	Event source (1 - 8).
%z	Event	Event source (Syslog - Group).

Global Settings for Login Alert Messages

In SL1, administrators can add a customizable click-through alert message as a security measure at logon. Users will not be able to access the system until the user click the OK button to agree to the terms and conditions of use for that system.

To add a custom login alert message to SL1:

Go to the Login Alert Editor page (System > Settings > Login Alert Message).
In the Alert Message field, type the text of your login alert message:

After entering the login alert text, click the Save button.
When a user logs in, the alert message will display:

Global Settings for Password Reset Emails

The Password Reset Email Editor page (Password Reset Email Editor) allows ScienceLogic administrators to define the email message that is sent to ScienceLogic users who select the "I forgot my password" option from the Login page.

If the user enters a valid ScienceLogic username in the Login page and then selects the I forgot my password option, SL1 will check the account information for that user. If the user's account information includes an email address, SL1 will send the user an email message. The email message will include a link that allows the user to redefine their ScienceLogic password. The new password must meet the requirements defined in the Password Strength field and the Password Shadowing field for the user account. SL1 will prompt the user to meet these requirements and display a description of those requirements.

The user can select the I forgot my password option up to ten times without responding to the sent email (using the link in the email to reset the password). After ten times, SL1 will no longer send another email message to the user's email address. The user can continue to select the I forgot my password option, but SL1 will not resend an email.

If the user's account information does not include an email address, SL1 displays the message "Password recovery is not available for your account, please contact your system administrator".

If the user does not enter a valid ScienceLogic username in the Login page, the I forgot my password option is still displayed, but SL1 does not send an email. This prevents intruders from guessing ScienceLogic account names.

If the user exceeds the number of login tries (defined in the Behavior Settings page), the "I forgot my password" option is not displayed in the Login page.

Defining the Email Message for "I forgot my password"

In the Password Reset Email Editor page (System > Settings > Password Reset Email), you can define the email that is sent from SL1 when an end user selects the I forgot my password option from the Login page.

To define the email message sent by SL1:

Go to the Password Reset Email Editor page (System > Settings > Password Reset Email).

Supply a value in each of the following fields:

Priority. This will be the priority of the email message. Choices are:

High. Emails will be marked as high priority.
Normal. Emails will be marked as normal priority.
Low. Emails will be marked as low priority.

Subject. This will be the subject of the email message.
Message. This will be the body of the email message. The body must include the variable %L. This variable inserts the link to the page that allows the user to reset their ScienceLogic password.

You can include the following variables in the Subject field and the Message field:

%L (uppercase "el"). The link to the page that allows the user to reset their password.
%O (uppercase "oh"). The user's primary organization, as defined in the Account Permissions page for the user.

%fn (lowercase "eff" "en"). The user's first name, as defined in the Account Permissions page for the user.
%ln (lowercase "el "en". The user's last name, as defined in the Account Permissions page for the user.

Click the Save button to save the email template.
When a user follows the link in the email, SL1 displays the Login page, with the message "Your account has been reset. Please create a new password." The user must then enter their new password twice. The new password is recorded in SL1 and replaces the previous (forgotten) password.

For example, you could define the following:

Subject. ScienceLogic | %O (automated message)

Message. Hello %fn %ln,

Your password for account %A has been reset.

Please use the following link to log in and choose a new password:

%L.

For the user "Keyser Soze", who is a member of the System organization, the following email would be sent:

Subject: ScienceLogic | System (automated message).

Hello Keyser Soze,

Your password for account ksoze has been reset.

Please use the following link to login and choose a new password:

https://name_or_IP_of_EM7_Administration_Portal/login.em7?prs=hash

Global Settings for System Thresholds

The System Threshold Defaults page (System > Settings > Thresholds > System) allows you to define global thresholds for system latency, file system usage, counter rollovers, ICMP availability, number of component devices, interface inventory, and inbound messages.

These settings apply to all devices. However, you can override these system settings on a case-by-case basis. For example, you can define thresholds for a device's file systems in the Thresholds tab of the Device Investigator (or the Device Thresholds page in the classic SL1 user interface). The settings you define for the specific device override the settings in the System Threshold Defaults page.

To edit the global settings for system thresholds:

Go to the System Threshold Defaults page (System > Settings > Thresholds > System).

In the System Threshold Defaults page, you can drag sliders to change to value of each field or edit a field manually. You can edit the value for one or more of the following fields:

System Latency. During polling, the platform initially pings monitored devices. The value in this field is the maximum number of milliseconds for the device to respond to SL1's ping (round-trip time divided by 2). The default value is 100 ms. When the latency threshold is exceeded, SL1 generates an event for that device.
System Availability. During polling, SL1 monitors devices for availability. Availability means the device's ability to accept connections and data from the network. The value in this field is the percent availability required of each device. The default value is 99%. When a device falls below this level of availability, SL1 generates an event for that device.

During polling, a device has two possible availability values:

100%. Device is up and running.
0%. Device is not accepting connections and data from the network.

Component devices use a Dynamic Application collection object to measure availability. SL1 polls component devices for availability at the frequency defined in the Dynamic Application. For details, see the section on monitoring availability of component devices.

NOTE: The Ping & Poll Timeout (Msec) setting in the Behavior Settings page (System > Settings > Behavior) affects how SL1 monitors device availability. This field specifies the number of milliseconds the discovery tool and availability polls will wait for a response after pinging a device. After the specified number of milliseconds have elapsed, the poll will timeout.

File System Major. Threshold that will trigger a "low disk space" event. The default threshold is 85%. When a device has used more disk space than the specified percentage, SL1 will generate a "file system usage exceeded threshold" event with a status of "major".

File System Critical. Threshold that will trigger a "low disk space" event. The default threshold is 95%. When a device has used more disk-space than the specified percentage, SL1 will generate a "file system usage exceeded threshold" event with a status of "critical".

NOTE: If you hide a file system in the Device Hardware page (Devices > Hardware), SL1 does not generate events for that file system.

Rollover Percent. For any collected data that uses a 32-bit counter, you can specify how SL1 determines that the counter has "rolled over", that is, has reached its maximum value, is reset to zero, and restarts counting. When this happens, the collected values go from the maximum value to a lower value. However, there are multiple circumstances under which a counter value can go from a higher value to a lower value:

Maximum value has been exceeded and counter was reset to zero.
Retrieved value was manually reset to zero on the external device.
Data was collected out-of-order, that is, due to a slowdown somewhere in the network, two counter values were stored out of sequence.

NOTE: For 64-bit counters, when the counter values go from a higher value to a lower value, SL1 assumes that the counter has been manually reset or that the two values were collected out of order. SL1 does not assume that the counter has rolled over.

The Rollover Percent field allows you to specify a threshold that indicates that a 32-bit counter has reached its maximum value and restarted counting. The default value is 20%. When SL1 records a counter value that is lower than the previously collected value, the platform:

Calculates the difference between the two counter values (the delta):

232 - Last Collected Value + Current Collected Value

Examines the value of the Rollover Percent threshold. If the delta is less than the specified percentage of the maximum possible value (232), SL1 concludes that the 32-bit counter rolled over.
For example, if you specified "25" in this field, SL1 would determine if the delta is less than 25% of the maximum possible value. If the delta is less than 25% of the maximum possible value, SL1 concludes that the 32-bit counter rolled over.
When SL1 determines a counter has rolled over, SL1 uses the delta value when displaying the data point for this poll period.

The Rollover Percent field applies only to 32-bit counters. If a 64-bit counter value goes from a higher value to a lower value, the change is treated as either a manual reset or an out-of-order collection.

Out-of-order Percent. For any collected data that uses a counter, you can specify how SL1 determines that data has been collected out of order. When this data is collected out of order, the collected values go from a higher value to a lower value. However, there are multiple circumstances under which a counter value can go from a higher value to a lower value:

Maximum value has been exceeded and counter was reset to zero (for 32-bit counters only).
Data was collected out-of-order, that is, due to a slowdown somewhere in the network, two counter values were stored out of sequence.
Retrieved value was manually reset to zero on the external device.

The Out-of-order Percent field allows you to specify a threshold that indicates that data has been collected out of order. The default value is 50%. When SL1 records a counter value that is lower than the previously collected value and the platform has determined that the value is not a rollover, SL1:

Compares the current value to the last collected value:

current value / last collected value

If the ratio of current value / last collected value is greater than the percent specified in the Out-of-order Percent field, SL1 concludes that the data was collected out of order.
When SL1 determines a data point has been collected out of order, SL1 uses the following value as the current value of the data point:

last collected value - current collected value

NOTE: If a 32-bit counter value goes from the maximum value to a lower value, and the current collected value does not meet the criteria for a rollover AND the current collected value does not meet the criteria for out-of-order, SL1 concludes that the 32-bit counter was manually reset to zero (0). SL1 uses the current collected value for this data point.

NOTE: If a 64-bit counter value goes from a higher value to a lower value, and the current collected value does not meet the criteria for out-of-order, SL1 concludes that the 64-bit counter was manually reset to zero (0). SL1 uses the current collected value for this data point.

Availability Ping Count. If you select ICMP in the Availability Port field in the Device Properties page (Devices> Device Manager > wrench icon) for a device, this field specifies the number of packets that should be sent during each availability check. The default value is "1".
Avail Required Ping Percentage. If you select ICMP in the Availability Port field in the Device Properties page (Devices> Device Manager > wrench icon) for a device, this field specifies the percentage of packets that must be returned during an availability check for SL1 to consider the device available. The default value is "100%".

Process Runtime Threshold Low. Threshold that will trigger a "process time exceeded" event. The default threshold is 80%. When a process has used more than 80% of its allowed Run Length, SL1 will generate a "process time exceeded threshold" event with a status of "minor".

Process Runtime Threshold High. Threshold that will trigger a "process time exceeded" event. The default threshold is 100%. When a process has used 100% of its allowed Run Length, SL1 will generate a "process time exceeded threshold" event with a status of "major".

NOTE: Run Length is defined in the Process Manager page (System > Settings > Admin Processes).

Component Purge Timeout. This field specifies the number of hours a device can be set to "vanished" before SL1 purges the component device. When a device is purged, SL1 stops trying to collect data about the component device. The purged device will not appear in reports or views on in any pages in the user interface. When a device is purged, all of its configuration data and collected data is deleted from the Database Server. If you set this value to "0", component devices are never purged. You can override this threshold for a specific device in the Thresholds tab of the Device Investigator (or the Device Thresholds page in the classic SL1 user interface) for the device.

NOTE: When a device is set to "vanished", all children of that device are also set to "vanished". When a device is purged, all children of that device are also purged.

Component Vanish Timeout Mins. If SL1 cannot retrieve information from a root device about a component device, this field specifies how many minutes to wait until putting the component device into "vanish" mode. When a device is set to "vanished", SL1 stops trying to collect data about the component device. The vanished device will not appear in reports or views. The vanished device will appear in the Vanished Device Manager page. If you set this value to "0", component devices are never set to "vanished". You can override this threshold for a specific device in the Thresholds tab of the Device Investigator (or the Device Thresholds page in the classic SL1 user interface) for the device.

Interface Inventory Timeout. Specifies the maximum amount of time that the discovery processes will spend polling a device for the list of interfaces. After the specified time, SL1 will stop polling the device, will not model the device, and will continue with discovery. The default value is 600,000 ms (10 minutes).

During initial discovery, initiated from the Discovery Session Editor page (System > Manage > Classic Discovery > Create), SL1 uses the value in this field if there is no differing value specified in the Discovery Session Editor page.

During re-discovery (clicking the binocular icon () in the Device Properties page), SL1 will use the value in this field if there no value is specified in the Thresholds tab of the Device Investigator (or the Device Thresholds page in the classic SL1 user interface) for the device.

During nightly auto-discovery (run automatically by SL1 every night, to update device information), SL1 uses the value in this field if no differing value is specified in the Thresholds tab of the Device Investigator (or the Device Thresholds page in the classic SL1 user interface) for a device.

Maximum Allowed Interfaces. Specifies the maximum number of interfaces per device. If a device exceeds this number of interfaces, SL1 will stop scanning the device, will not model the device, and will continue with discovery. The default value is 10,000.

During initial discovery, initiated from the Discovery Session Editor page (System > Manage > Classic Discovery > Create), SL1 uses the value in this field if there is no differing value specified in the Discovery Session Editor page.
During re-discovery (clicking the binocular icon () in the Device Properties page), SL1 will use the value in this field if there is no differing value is specified in the Thresholds tab of the Device Investigator (or the Device Thresholds page in the classic SL1 user interface) for the device.
During nightly auto-discovery (run automatically by SL1 every night, to update device information), SL1 uses the value in this field if no differing value is specified in the Thresholds tab of the Device Investigator (or the Device Thresholds page in the classic SL1 user interface) for a device.

Inbound Message Throttle Thresholds. Specifies the maximum number of messages that can be received before SL1 will notify the system administrator and discard the current batch of messages. The default message threshold is 25.

Syslog per-IP. Specifies the threshold for incoming syslog messages from a given IP address.
Dynamic Alert per-device. Specifies the threshold for incoming alerts for a Dynamic Application on a given device.
SNMP Trap per-IP. Specifies the threshold for incoming SNMP traps from a given IP address.

SSL Certificate Purge Timeout. Specifies the number of days after which SSL certificate data will be purged. The default value is 0 days.
Schedules Purge Timeout. Specifies the number of days after which expired schedules will be deleted. The default value is 730 days.

Click the Save button to save changes in this page.
All changes to this page are logged in the audit logs.

Global Settings for Interface Thresholds

The Interface Thresholds Defaults page (System > Settings > Thresholds > Interface) allows you to define global thresholds for interfaces.

The settings in the Interface Thresholds Defaults page apply to all interfaces. However, you can override these system settings on a case-by-case basis for each interface in the Thresholds tab on the Interface Properties page (Registry > Networks > Interfaces > interface wrench icon).

If you have specified that SL1 should monitor an interface, SL1 will collect data about the interface and also monitor performance thresholds for the interface. SL1 will use either the default thresholds defined in the Interface Thresholds Defaults page (System > Settings > Thresholds > Interface or the custom threshold you define in the Thresholds tab on the Interface Properties page (Registry > Networks > Interfaces > interface wrench icon). When the values for an interface exceed one or more thresholds, SL1 will generate an event.

To define global thresholds for interfaces:

Go to Interface Thresholds Defaults page (System > Settings > Thresholds > Interface.

The following global thresholds are defined by default in the Interface Thresholds Defaults page:

NOTE: You can specify the unit of measure for all the metrics in Bandwidth In and Bandwidth Out. You can select bps, kbps, Mbps (the default), or Gbps.

Threshold	Default Value	Default Status
Utilization % In > Inbound Percent	65.000	Enabled
Utilization % Out > Outbound Percent	65.000	Enabled
Bandwidth In > Inbound Bandwidth	0.000	Disabled
Bandwidth Out > Outbound Bandwidth	0.000	Disabled
Errors % In > Inbound Error Percent	1.000	Enabled
Errors % Out > Outbound Error Percent	1.000	Enabled
Errors In > Inbound Errors	1000.000	Enabled
Errors Out > Outbound Errors	1000.000	Enabled
Discard % In > Inbound Discard Percent	1.000	Enabled
Discards % Out > Outbound Discard Percent	1.000	Enabled
Discards In > Inbound Discards	1000.000	Enabled
Discards Out > Outbound Discards	1000.000	Enabled
Multicast % In > Rising Medium	30.000	Disabled
Multicast % In > Rising Low	20.000	Disabled
Broadcast % Out > Rising Medium	30.000	Disabled
Broadcast % Out > Rising Low	20.000	Disabled

Selecting the Show Hidden Thresholds checkbox displays the following default thresholds:

NOTE: You can specify the unit of measure for all the metrics in Bandwidth In and Bandwidth Out. You can select bps, kbps, Mbps (the default), or Gbps.

Threshold	Default Value	Default Status
Utilization % In > Rising High	0.000	Hidden
Utilization % In > Rising Medium	0.000	Hidden
Utilization % In > Rising Low	0.000	Hidden
Utilization % In > Falling Low	0.000	Hidden
Utilization % In > Falling Medium	0.000	Hidden
Utilization % In > Falling High	0.000	Hidden
Utilization % In > Inbound Percent	65.000	Enabled
Utilization % Out> Rising High	0.000	Hidden
Utilization % Out > Rising Medium	0.000	Hidden
Utilization % Out > Rising Low	0.000	Hidden
Utilization % Out > Falling Low	0.000	Hidden
Utilization % Out > Falling Medium	0.000	Hidden
Utilization % Out > Falling High	0.000	Hidden
Utilization % Out > Outbound Percent	65.000	Enabled
Bandwidth In > Rising High	0.000	Hidden
Bandwidth In > Rising Medium	0.000	Hidden
Bandwidth In > Rising Low	0.000	Hidden
Bandwidth In > Falling Low	0.000	Hidden
Bandwidth In > Falling Medium	0.000	Hidden
Bandwidth In > Falling High	0.000	Hidden
Bandwidth In > Inbound Bandwidth	0.000	Disabled
Bandwidth Out > Rising High	0.000	Hidden
Bandwidth Out > Rising Medium	0.000	Hidden
Bandwidth Out > Rising Low	0.000	Hidden
Bandwidth Out > Falling Low	0.000	Hidden
Bandwidth Out > Falling Medium	0.000	Hidden
Bandwidth Out > Falling High	0.000	Hidden
Bandwidth Out > Outbound Bandwidth	0.000	Disabled
Errors % In > Rising High	0.000	Hidden
Errors % In > Rising Medium	0.000	Hidden
Errors % In > Rising Low	0.000	Hidden
Errors % In > Falling Low	0.000	Hidden
Errors % In > Falling Medium	0.000	Hidden
Errors % In > Falling High	0.000	Hidden
Errors % In > Inbound Error Percent	1.000	Enabled
Errors % Out > Rising High	0.000	Hidden
Errors % Out > Rising Medium	0.000	Hidden
Errors % Out > Rising Low	0.000	Hidden
Errors % Out > Falling Low	0.000	Hidden
Errors % Out > Falling Medium	0.000	Hidden
Errors % Out > Falling High	0.000	Hidden
Errors % Out > Outbound Error Percent	1.000	Enabled
Errors In > Rising High	0.000	Hidden
Errors In > Rising Medium	0.000	Hidden
Errors In > Rising Low	0.000	Hidden
Errors In > Falling Low	0.000	Hidden
Errors In > Falling Medium	0.000	Hidden
Errors In > Falling High	0.000	Hidden
Errors In > Inbound Errors	1000.000	Enabled
Errors Out > Rising High	0.000	Hidden
Errors Out > Rising Medium	0.000	Hidden
Errors Out > Rising Low	0.000	Hidden
Errors Out > Falling Low	0.000	Hidden
Errors Out > Falling Medium	0.000	Hidden
Errors Out > Falling High	0.000	Hidden
Errors Out > Outbound Errors	1000.000	Enabled
Discards % In > Rising High	0.000	Hidden
Discards % In > Rising Medium	0.000	Hidden
Discards % In > Rising Low	0.000	Hidden
Discards % In > Falling Low	0.000	Hidden
Discards % In > Falling Medium	0.000	Hidden
Discards % In > Falling High	0.000	Hidden
Discards % In > Inbound Discard Percent	1.000	Enabled
Discards % Out > Rising High	0.000	Hidden
Discards % Out > Rising Medium	0.000	Hidden
Discards % Out > Rising Low	0.000	Hidden
Discards % Out > Falling Low	0.000	Hidden
Discards % Out > Falling Medium	0.000	Hidden
Discards % Out > Falling High	0.000	Hidden
Discards % Out > Outbound Discard Percent	1.000	Enabled
Discards In > Rising High	0.000	Hidden
Discards In > Rising Medium	0.000	Hidden
Discards In > Rising Low	0.000	Hidden
Discards In > Falling Low	0.000	Hidden
Discards In > Falling Medium	0.000	Hidden
Discards In > Falling High	0.000	Hidden
Discards In > Inbound Discards	1000.000	Enabled
Discards Out > Rising High	0.000	Hidden
Discards Out > Rising Medium	0.000	Hidden
Discards Out > Rising Low	0.000	Hidden
Discards Out > Falling Low	0.000	Hidden
Discards Out > Falling Medium	0.000	Hidden
Discards Out > Falling High	0.000	Hidden
Discards Out > Outbound Discards	1000.000	Enabled
Broadcast % In > Rising High	0.000	Hidden
Broadcast % In > Rising Medium	30.000	Disabled
Broadcast % In > Rising Low	20.000	Disabled
Broadcast % In > Falling Low	0.000	Hidden
Broadcast % In > Falling Medium	0.000	Hidden
Broadcast % In > Falling High	0.000	Hidden
Broadcast % Out > Rising High	0.000	Hidden
Broadcast % Out > Rising Medium	30.000	Disabled
Broadcast % Out > Rising Low	20.000	Disabled
Broadcast % Out > Falling Low	0.000	Hidden
Broadcast % Out > Falling Medium	0.000	Hidden
Broadcast % Out > Falling High	0.000	Hidden
Broadcast In > Rising High	0.000	Hidden
Broadcast In > Rising Medium	0.000	Hidden
Broadcast In > Rising Low	0.000	Hidden
Broadcast In > Falling Low	0.000	Hidden
Broadcast In > Falling Medium	0.000	Hidden
Broadcast In > Falling High	0.000	Hidden
Broadcast Out > Rising High	0.000	Hidden
Broadcast Out > Rising Medium	0.000	Hidden
Broadcast Out > Rising Low	0.000	Hidden
Broadcast Out > Falling Low	0.000	Hidden
Broadcast Out > Falling Medium	0.000	Hidden
Broadcast Out > Falling High	0.000	Hidden
Multicast % In > Rising High	0.000	Hidden
Multicast % In > Rising Medium	00.000	Hidden
Multicast % In > Rising Low	00.000	Hidden
Multicast % In > Falling Low	0.000	Hidden
Multicast % In > Falling Medium	0.000	Hidden
Multicast % In > Falling High	0.000	Hidden
Multicast % Out > Rising High	0.000	Hidden
Multicast % Out > Rising Medium	00.000	Hidden
Multicast % Out > Rising Low	00.000	Hidden
Multicast % Out > Falling Low	0.000	Hidden
Multicast % Out > Falling Medium	0.000	Hidden
Multicast % Out > Falling High	0.000	Hidden
Multicast In > Rising High	0.000	Hidden
Multicast In > Rising Medium	0.000	Hidden
Multicast In > Rising Low	0.000	Hidden
Multicast In > Falling Low	0.000	Hidden
Multicast In > Falling Medium	0.000	Hidden
Multicast In > Falling High	0.000	Hidden
Multicast Out > Rising High	0.000	Hidden
Multicast Out > Rising Medium	0.000	Hidden
Multicast Out > Rising Low	0.000	Hidden
Multicast Out > Falling Low	0.000	Hidden
Multicast Out > Falling Medium	0.000	Hidden
Multicast Out > Falling High	0.000	Hidden
Unicast % In > Rising High	0.000	Hidden
Unicast % In > Rising Medium	00.000	Hidden
Unicast % In > Rising Low	00.000	Hidden
Unicast % In > Falling Low	0.000	Hidden
Unicast % In > Falling Medium	0.000	Hidden
Unicast % In > Falling High	0.000	Hidden
Unicast % Out > Rising High	0.000	Hidden
Unicast % Out > Rising Medium	00.000	Hidden
Unicast % Out > Rising Low	00.000	Hidden
Unicast % Out > Falling Low	0.000	Hidden
Unicast % Out > Falling Medium	0.000	Hidden
Unicast % Out > Falling High	0.000	Hidden
Unicast In > Rising High	0.000	Hidden
Unicast In > Rising Medium	0.000	Hidden
Unicast In > Rising Low	0.000	Hidden
Unicast In > Falling Low	0.000	Hidden
Unicast In > Falling Medium	0.000	Hidden
Unicast In > Falling High	0.000	Hidden
Unicast Out > Rising High	0.000	Hidden
Unicast Out > Rising Medium	0.000	Hidden
Unicast Out > Rising Low	0.000	Hidden
Unicast Out > Falling Low	0.000	Hidden
Unicast Out > Falling Medium	0.000	Hidden
Unicast Out > Falling High	0.000	Hidden

For each threshold, you can edit the following:

Value. The value at which the threshold will trigger an event.

For thresholds that include the word Rising, when a value exceeds the specified value, SL1 triggers an event.
For thresholds that include the word Falling, when a value falls below the specified value, SL1 triggers an event.
For thresholds that do not include the word Rising or Falling, when a value exceeds the specified value, SL1 triggers an event.

Status. Specifies whether the threshold is active and whether the threshold will appear in the Thresholds tab on the Interface Properties page (Registry > Networks > Interfaces > interface wrench icon). Choices are:

Enabled. The threshold is applied to all interfaces and is monitored by SL1. The threshold appears in the Thresholds tab on the Interface Properties page (Registry > Networks > Interfaces > interface wrench icon). Users can edit the Value and Status of the threshold.

Disabled. The threshold is applied to all interfaces but is not monitored by SL1. The threshold appears in the Thresholds tab on the Interface Properties page (Registry > Networks > Interfaces > interface wrench icon) with a status of Disabled. In the Thresholds tab on the Interface Properties page, users can edit the Value and Status of the threshold.
Hidden. The threshold is not applied to all interfaces, and is not monitored by SL1. The threshold does not appear in the Thresholds tab on the Interface Properties page (Registry > Networks > Interfaces > interface wrench icon).

Unit of Measure. For all the metrics under Bandwidth In and Bandwidth Out, you can select the unit of measure. Choices are:

kbps
Mbps
Gbps

Settings in Silo.Conf

Every SL1 appliance has a configuration file called silo.conf, which contains configuration information about the appliance itself, such as the IP address, licensing information, and directory locations. The default settings in silo.conf are configured automatically when the appliance is installed. The following section describes how you can add additional, non-default settings to silo.conf.

ScienceLogic recommends that you do not edit the values in these files without first consulting ScienceLogic. Incorrect values can severely disrupt platform operations.

All settings in these .conf files are case-sensitive.

To edit the silo.conf file:

Either go to the console of the SL1 appliance or use SSH to access the SL1 appliance.
Open a shell session on the server.
Type the following at the command line:

sudo visilo

For ISO installs of SL1 version 11.3.0 and later, password information in the silo.conf file is automatically encrypted when the file is modified using visilo. Users can no longer decrypt passwords in the silo.conf file.

You can use the ap_user and ap_pass fields to define usernames and passwords for the Administration Portal that differ from the usernames and passwords used for the Database Server.

You can add or edit one or more of the following settings:

store_timeout. You can edit this setting in the silo.conf file on each Database Server. When the Database Server pulls collected data back from Data Collectors and Message Collectors, each piece of data (called a storage object) must be stored within a set amount of time. The default timeout for a storage object is ten seconds. To change the timeout for all storage objects, add the following line to the silo.conf file on the Database Server:

store_timeout=xx

where xx is the timeout in seconds.

If you change this setting (for example, change the value to 30 seconds), you must stop and restart the high frequency, medium frequency, and low frequency data pull processes for the change to be applied.

The store_timeout setting does not apply to All-In-One Appliances.

eventmanager. You can edit this setting in the silo.conf file on each SL1 appliance. You can modify this default setting to allow API events to be processed on a Data Collector. The default configuration is:

eventmanager = internal,dynamic,syslog,trap

To allow a Data Collector to process API events, change this line to

eventmanager = internal,dynamic,syslog,trap,api

Do not make any other changes to this setting or modify this setting on a Database Server or Data Collector.

report_memory_limit. You can edit this setting in the silo.conf file on each SL1 appliance that provides the user interface (an Administration Portal, Database Server, or All-In-One Appliance). If report_memory_limit is not defined in silo.conf, the default value is three gigabytes (3G). If reports are failing to be generated due to a lack of memory, you can increase this value.

To increase report memory, add the following line to the [LOCAL] section of silo.conf on each SL1 appliance the provides the user interface for your system. In most cases, this will be the Administration Portal (for distributed system) or the All-In-One Appliance:

report_memory_limit=XY

where:

X is a positive integer
Y represents units. Value can be K (kilobytes), M (megabytes), or G (gigabytes),

For example, if reports are failing to be generated due to a lack of memory, you could add the following line to silo.conf:

report_memory_limit=4G

You should add the report_memory_limit option to the silo.conf file on a Database Server only if there are no Administration Portals configured in your system.

You must add the same report_memory_limit setting to every Administration Portal configured in your system.

use_v1trap_envelope_addr. You can edit this setting in the silo.conf file on each Data Collectors, Data Collectors that perform message collection, and All-In-One Appliances. In environments where Network Address Translation is performed on SNMP v1 trap messages sent to SL1, you can configure the platform to read the envelope address (the address of the host sending the trap) instead of the agent address (the IP address variable sent as part of the trap). If use_v1trap_envelope_addr is not defined in silo.conf, SL1 will use the agent address for SNMP v1 trap messages.

To use the envelope address instead of the agent address for SNMP v1 trap messages, add the following line to the [LOCAL] section of silo.conf on Data Collectors, Data Collectors that perform message collection, and All-In-One Appliances

use_v1trap_envelope_addr=1
To use the agent address for SNMP v1 trap messages, you can either omit the use_v1_trap_envelope_addr setting or add the following line to the [LOCAL] section of silo.conf on Data Collectors, Data Collectors that perform message collection, and All-In-One Appliances

use_v1trap_envelope_addr=0

disable_itil_compliance. You can edit this setting in the silo.conf file on each If you enable this setting on an appliance that provides the user interface (an Administration Portal, Database Server, or All-In-One Appliance), the Ticket Console page on that appliance will include an option to delete tickets. The option to delete tickets will appear only to users that have been granted the Ticket: Delete access hook and users of type "administrator".

To enable this setting, add the following line to the [LOCAL] section of silo.conf on the appliance that provides the user interface (Administration Portal, Database Server, or All-In-One Appliance):

disable_itil_compliance=1
suppress_ticket_link. You can edit this setting in the silo.conf file on each SL1 appliance that provides the user interface (an Administration Portal, Database Server, or All-In-One Appliance). If you enable this setting, automatic notifications that are generated when a ticket is created or updated will not include a hyperlink to the ticket.

To enable this setting, add the following line to the [LOCAL] section of silo.conf on SL1 appliance that provides the user interface (Administration Portal, Database Server, or All-In-One Appliance):

suppress_ticket_link=1
mailparse_interval. You can edit this setting in the silo.conf file on each Database Server or All-In-One Appliance. The mailparse_interval setting defines how frequently the mail parsing process reads email messages from the mailbox. If the mailparse_interval setting is not defined in silo.conf, the default value is 60 seconds. When an email is received by SL1, the mail parsing process on the primary Database Server or All-In-One Appliance reads the email message from the mailbox file and sends it to one of the three processes responsible for acting on that email: the event engine (for events from email), the tickets from email process, or the round-trip email collection process.

To enable this setting, add the following line to the [LOCAL] section of silo.conf on each Database Server or All-In-One Appliance:

mailparse_interval=X

where X is the frequency at which the mailbox will be read, in seconds. Valid values are 15 seconds to 60 seconds.

dynamic_collect_num_chunk_workers. You can edit this setting in the silo.conf file on each Database Server or All-In-One Appliance. This setting represents the number of workers that handle collection requests. SL1 first sorts collection requests into groups by execution environment and sends each group of collection requests (called a chunk) to a worker process. This worker process is called a chunk worker. For each chunk, a chunk worker creates the execution environment and creates a pool of request workers to process the collection requests. The number of chunk workers generally represents the number of PowerPacks that can be processed in parallel. The default value for this parameter is "2".

To change this setting, add the following line to the [LOCAL] section of silo.conf on each Database Server or All-In-One Appliance:

dynamic_collect_num_chunk_workers = [X]

where X is the number of chunk workers

For more information about using dynamic_collect_num_chunk_workers, see the section on Tuning the Collector Load Balancing Process in the Silo.Conf File.

dynamic_collect_num_request_workers. You can edit this setting in the silo.conf file on each Database Server or All-In-One Appliance. This setting represents the maximum number of request workers in each worker pool and generally represents the number of collections within a PowerPack that can be processed in parallel. The default value for this parameter is "2" or the number of cores on the Data Collector, whichever is greater.

To change this setting, add the following line to the [LOCAL] section of silo.conf on each Database Server or All-In-One Appliance:

dynamic_collect_num_request_workers = [X]

where:

X is the maximum number of request workers in each worker pool.

For more information about using dynamic_collect_num_request_workers, see the section on Tuning the Collector Load Balancing Process in the Silo.Conf File.

dynamic_collect_request_chunk_size. You can edit this setting in the silo.conf file on each Database Server or All-In-One Appliance. This setting represents the maximum number of collection requests in a chunk and controls how many collections are processed by a single pool or request workers. The default value for this parameter is "200".

To change this setting, add the following line to the [LOCAL] section of silo.conf on each Database Server or All-In-One Appliance:

dynamic_collect_request_chunk_size = [X]

where:

X is the maximum number of collection requests in a chunk.

For more information about using dynamic_collect_request_chunk_size, see the section on Tuning the Collector Load Balancing Process in the Silo.Conf File.

read_timeout. You can edit this setting in the silo.conf file on each Database Server. This setting controls the client read timeout for database connections to the collectors. This setting applies only to the Enterprise Database: Collector Config Push process (config_push.py) that runs on the primary Database Server.

Change this value only if you are instructed to do so by ScienceLogic.

To change this setting, add the following line to the [CONFIG_PUSH] section of silo.conf on all Database Servers in your system.

read_timeout=X

where:

X is the read timeout, in seconds.

wait_timeout. You can edit this setting in the silo.conf file on each Database Server. This setting controls the server wait timeout for database connections to the collectors. This setting applies only to the Enterprise Database: Collector Config Push process (config_push.py) that runs on the primary Database Server.

Change this value only if you are instructed to do so by ScienceLogic.

To change this setting, add the following line to the [CONFIG_PUSH] section of silo.conf on all Database Servers in your system.

wait_timeout=X

where:

X is the write timeout, in seconds.

write_timeout. You can edit this setting in the silo.conf file on each Database Server. This setting controls the client write timeout for database connections to the collectors. This setting applies only to the Enterprise Database: Collector Config Push process (config_push.py) that runs on the primary Database Server.

Change this value only if you are instructed to do so by ScienceLogic.

write_timeout=X

where:

X is the write timeout, in seconds.

memory_limit. You can edit this setting in the silo.conf file on each Database Server. This setting controls the memory limit for the Enterprise Database: Collector Config Push process. This setting applies only to the Enterprise Database: Collector Config Push process (config_push.py) that runs on the primary Database Server.

Change this value only if you are instructed to do so by ScienceLogic.

To change this setting, add the following line to the [CONFIG_PUSH] section of silo.conf on all Database Servers in your system.

memory_limit=XY

where:

X is a positive integer.
Y represents units. Value can be KB (kilobytes), MB (megabytes), or GB (gigabytes).

result_wait_timeout. You can edit this setting in the silo.conf file on each Database Server. This setting controls the amount of time the parent Enterprise Database: Collector Config Push process will wait for a message from a child process before abandoning that process. This setting applies only to the Enterprise Database: Collector Config Push process (config_push.py) that runs on the primary Database Server

Change this value only if you are instructed to do so by ScienceLogic.

To change this setting, add the following line to the [CONFIG_PUSH] section of silo.conf on all Database Servers in your system.

result_wait_timeout=X

where:

X is the write timeout, in seconds.

shutdown_timeout. You can edit this setting in the silo.conf file on each Database Server. If the Enterprise Database: Collector Config Push process is terminated, this setting controls the amount of time the parent configuration process will wait for its child processes to stop before terminating itself and allowing the child processes to be inherited by init. This setting applies only to the Enterprise Database: Collector Config Push process (config_push.py) that runs on the primary Database Server.

Change this value only if you are instructed to do so by ScienceLogic.

To change this setting, add the following line to the [CONFIG_PUSH] section of silo.conf on all Database Servers in your system.

shutdown_timeout=X

where:

X is the write timeout, in seconds.

[PROC_VIRTUAL_MEM_LIMIT]. By default, processes in SL1 have a virtual memory limit of 1 GB. You can edit this section in the silo.conf file to overwrite the existing virtual memory limit for a given process in SL1 to ensure that it does not fail by crossing its virtual memory limit.

To change this setting, add the [PROC_VIRTUAL_MEM_LIMIT] section to the silo.conf file. Below that section heading, specify the process you want to update and the new virtual memory limit for that process. Use the following format for each setting:

[process ID]=X

where:

[process ID] is the ID of the process you want to update, as found in master.system_settings_procs.aid
X is the new virtual memory limit, in bytes

For example, if you wanted to update a process with an ID of "12" with a new 2 GB memory limit, you would write the following under [PROC_VIRTUAL_MEM_LIMIT]:

12=2147483648

[ADHOC_REPORT_IN_BATCH]. ad hoc reports are processed in a batch process. You can edit this section in the silo.conf file to overwrite the default timing values for certain ad hoc reporting settings.

To change these settings, under the [ADHOC_REPORT_IN_BATCH] section heading in the silo.conf file, specify the time value (in seconds) for each setting. The following settings are included in the [ADHOC_REPORT_IN_BATCH] section:

report_execution_delay. This setting controls the amount of time between when a report is scheduled to start running and when it actually begins running. Its default value is 10.
ajax_start_delay. This setting controls the amount of time elapsed before jQuery triggers the ajaxStart event. Its default value is 20.
ajax_stop_time. This setting controls the amount of time elapsed before jQuery triggers the ajaxStop event after all AJAX requests have completed. Its default value is 1800.
ajax_frequency. This setting controls the frequency with which jQuery fires AJAX requests. Its default value is 10.
ajax_frequency_decreased_after. This setting controls the amount of time elapsed after which jQuery will fire AJAX requests less frequently than in the ajax_frequency setting. Its default value is 300.
ajax_decreased_frequency. This setting controls the decreased frequency with which jQuery fires AJAX requests after the amount of time listed in the ajax_frequency_decreased_after setting has elapsed. Its default value is 60.
report_fail_check_time. This setting controls the amount of time elapsed after which a running report will be considered to have failed. Its default value is 10800.
auto_page_refresh. This setting controls the amount of time elapsed after which the Scheduled Report Jobs page (Report > Create Report > Scheduled Job / Report Archive) automatically refreshes. Its default value is 10.
about_to_start_time_check. This setting controls the amount of time before a report job is scheduled to start that it will be labeled as "About to start" on the Scheduled Report Jobs page (Report > Create Report > Scheduled Job / Report Archive). Its default value is 30.
time_unit. This setting controls the unit of time measurement for the ad hoc report settings. Its default value is "second".
ui_php_timeout. This setting controls the amount of time elapsed after which an inactive SL1 reports session will time out. Its default value is 1800.

To save your changes, click Save and then close the modal window.

All changes to the silo.conf file are logged in the SL1Database Server.

Disabling the User Interface on a Database Server

Database Servers are automatically configured to provide the user interface. If your SL1 system includes an Administration Portal, you might want to disable the user interface capability on your Database Server(s). Perform the following steps to disable the user interface capability on a Database Server:

To complete these steps, you must be familiar with how to edit a file using the vi text editor. If you need assistance with these steps, please contact ScienceLogic Support.

Log in to the console of the Database Server or use SSH to access the server as the em7admin user with the appropriate password.
Execute the following command to open the firewall rules file:

sudo vifirewalld
Add the following lines:

rule port port="443" protocol="tcp" reject

rule port port="80" protocol="tcp" reject
Save the file and exit the vi editor.
Execute the following commands to update and restart the firewall:

sudo /opt/em7/share/scripts/update-firewalld-conf.py