Global Settings

In Skylar One (formerly SL1), global settings allow you to define default behavior that applies to all elements in the platform. For settings that affect devices, you can override global settings with device-level settings.

Use the following menu options to navigate the Skylar One 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 Skylar One 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 Skylar One 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, Skylar One will write the standard entry to the audit log that indicates a user performed a write-operation using the API. However, Skylar One 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, Skylar One 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, Skylar One 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 Skylar One from writing to the ticket log for the ticket that was created or updated.

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

Only if X-EM7-send-notification:1 is sent. Skylar One will send notification emails for a ticket only when the X-EM7-send-notification header is set to 1.
Sent after every write operation. Skylar One 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.

During upgrade, table cells will highlight known, pending action items that must be done to successfully complete an upgrade, such as highlighting a Skylar One appliance that is running a different version of Skylar One 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.

From the Appliance Manager page, you can also:

Click the wrench icon () to edit the properties for each Skylar One appliance.
Click the toolbox icon () to access the Web Configuration Utility for each Skylar One appliance.
Click the agent endpoint icon () to access the Agent Endpoint Configuration modal for any Skylar One appliance that has a Skylar One Gen-1 agent installed.
Click the magnifying-glass icon () to view the output of the system status script for each Skylar One appliance.
Click the lock icon () to get a one-time password for each Skylar One appliance.
Click the lightning bolt icon () to run the Enterprise Database: Collector Config Push process (config_push.py) on any SL1 Collector appliance.
Click the delete icon () to delete a Skylar One appliance.

To edit and view information about a Skylar One appliance:

Go to the Appliance Manager page (System > Settings > Appliances).
Locate the Skylar One appliance you want to edit. Click its wrench icon (). The fields in the top pane are populated with values from the selected Skylar One 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, Skylar One 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.
PowerFlow (Skylar OnePowerFlow)

Description. Description of the appliance.
Sharing Permissions. Indicates if the appliance is shared or private. Choices are:
- Shared. The appliance can be viewed by users across all organizations.
- Private. The appliance can be viewed only by user accounts assigned to the System organization.
The Sharing Permissions field displays only for Administrator user accounts and user accounts assigned to the System organization.

You can also edit two optional fields for Data Collectors or Message Collectors:

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 Skylar One 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.

You can view the following information about each appliance that appears on the Appliance Manager page:

Name. Name of the appliance.
IP Address. Primary IP address for the appliance.
Module Type. Type of appliance.
Collector Group. For Data Collectors and All-In-One Appliances, specifies the Collector Group associated with the appliance.
Description. Description of the appliance.
Build. Specifies the latest build installed on the appliance.

If a Skylar One appliance is running a different version of Skylar One 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.
Platform. The current operating system platform version for the appliance. Potential values include el7 for appliances running on Oracle Linux 7 (OL7), el8 for appliances running on OL8, NULL, or Unknown. The platform value is highlighted when the primary Database Server is not running on the same platform version as the other appliances in the system.
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. Skylar One 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.
Access. Indicates whether the appliance is shared with all organizations or is private.

The Access column displays only for Administrator user accounts and user accounts assigned to the System organization.
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 Skylar One, and close the pop-up window for the Utility when you are done.
If a Skylar One appliance is running a different version of Skylar One 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 Skylar One appliances, Skylar One 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 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 delete 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 Skylar One 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 Skylar One. 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. 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 Skylar One appliance, configure interfaces, and edit settings for the Skylar One appliance and the Database Server if applicable.

For details on using the Configuration Utility to license a Skylar One 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 Skylar One.
Whether the field's value should be automatically updated by Skylar One.
Whether or not Skylar One 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 Skylar One.

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

Global Settings for System Behavior

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 Skylar One generates URLs for tickets or events (for example, in email messages), the trailing forward slash will be automatically included.
Require TLS Validation for Gen 1 Agent. When this checkbox is selected, Gen 1 agents that operate outside of the Extended Architecture will require TLS validation to upload data.
To enable this validation, all Data Collectors and Message Collectors that will ingest agent data must have a valid and signed TLS certificate.

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 Skylar One.
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.
365 Days. Passwords will expire after 365 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 Skylar One session expires. For better security, use a shorter time frame. By default, user sessions expire after 10 minutes of inactivity.
Page Auto-Refresh Keeps User Session Active. Specifies whether or not a user's Skylar One session stays active when a page in the system auto refreshes. This setting is disabled by default, and ScienceLogic recommends keeping it disabled for security purposes. If this setting is enabled, a user's Skylar One session will remain active if they are on a page that auto-refreshes, even if the amount of time specified in the User Login Session Timeout field elapses.
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, Skylar One will not allow another attempt for the number of seconds specified in this field. Choices are:

Disabled. Skylar One does not enforce a delay between failed logins.
1 Second. After a failed login, Skylar One will not allow another attempt for one second.
2 seconds. After a failed login, Skylar One will not allow another attempt for two seconds.
4 seconds. After a failed login, Skylar One will not allow another attempt for four seconds.
8 seconds. After a failed login, Skylar One 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 Skylar One, 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 Skylar One 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 Skylar One, 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 Skylar One 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 Skylar One system. Can be up to 128 characters in length. This field is useful for companies or organizations with multiple Skylar One systems. If a value is provided in this field, Skylar One will include a "system identifier" value in each event generated by the current Skylar One system. This allows users to easily determine the source Skylar One 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 Skylar One 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 or System > Manage > Discovery in the classic user interface) does not work for DHCP devices, Skylar One will automatically use the community string specified in this field.
Strip FQDN From Inbound Email Device Name. In Events from Email policies, specifies how Skylar One will match the regular expression for device name. Choices are:

Enabled. Skylar One 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), Skylar Onewill align the event with the matching device with the highest Device ID.
Disabled. Skylar One 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 Skylar One does not find an exact match in the incoming email, Skylar One 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, Skylar One 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), Skylar One 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, Skylar One 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, Skylar One automatically sends email notifications to all watchers when a ticket is created, assigned, or updated.
Disabled. When you select this option, Skylar One does not automatically send email notifications to all watchers when a ticket is created, assigned, or updated.

Force Child Ticket State and Status Inheritance. This checkbox specifies whether or not the state and status of a ticket is applied to child tickets.
Skylar Options (JSON). This field enables you to override the hard-coded default options for exporting metadata to Skylar. To do so, enter values in the same JSON structure as those that appear in the config.py file. For example:

DEFAULT_OPTIONS = { "metadata": { "intervals": {"snapshot": 60, "cleared_events": 5}, "snapshot": { "batch_sizes": { "asset_basic": 500, "asset_ip_config": 10000, "perf_index_label": 5000, "device_config": 20000, }, }, "cleared_events": { "query_range": 60, }, } }
Prevent Browser Saved Credentials. This checkbox specifies whether Skylar One 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 Skylar One. 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) in the footer. The user interface will display the following in the lower left of the footer:
- Last Login: mm-dd-yyyy hh-mm.
- Failed Login: mm-dd-yyyy hh-mm.

Ignore trap agent-addr varbind. If you select this checkbox, Skylar One 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 > Collection > Component Identifiers
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.
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 Skylar One. 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. Skylar One also uses this default value to perform timezone conversions when no user timezone setting is available. For example, if Skylar One 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 Skylar One from monitoring and reporting on NFS "shared" file systems. Skylar One will monitor and report only on local file systems.
Port Polling Type. Specifies how Skylar One 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. You can override this setting for a single discovery session in the Discovery Session Editor modal page. The options are:

0. Model Device Only. Discovery tool will discover if device is up and running and if so, collect the make and model of the device. Skylar One will then generate a device ID for the device, so it can be managed by Skylar One.
1. Initial Population of Apps. Discovery tool will search for Dynamic Applications to associate with the device. Discovery tool will attempt to collect data for the aligned Dynamic Applications. Discovery will also perform 0. Model Device Only discovery.
2. Discover SSL Certificates. Discovery tool will search for SSL certificates and retrieve SSL data. Discovery tool will also perform 1. Initial Population of Apps and 0. Model Device Only.
3. Discover Open Ports. Discovery tool will search for open ports. Discovery tool will also perform 2. Discover SSL Certificates, 1. Initial Population of Apps, and 0. Model Device Only. If your system includes a firewall and you select 3. Discover Open Ports, discovery might be blocked and/or might be taxing to your network.
4. Advanced Port Discovery. Discovery tool will search for open ports, using a faster TCP/IP connection method. Discovery tool will also perform 2. Discover SSL Certificates, 1. Initial Population of Apps, and 0. Model Device Only. If your system includes a firewall and you select 4. Advanced Port Discovery, some auto-discovered devices might remain in a pending state (purple icon) for some time after discovery. These devices will achieve a healthy status, but this might take several hours.
5. Deep Discovery. Discovery tool will use nmap to retrieve operating system name and version. Discovery will also scan for services running on each open port and can use this information to match devices to device classes. Discovery tool will search for open ports, using a faster TCP/IP connection method. Discovery tool will also perform 2. Discover SSL Certificates, 1. Initial Population of Apps, and 0. Model Device Only. For devices that don't support SNMP, option 5. Deep Discovery allows you to discover devices that don't support SNMP and then align those devices with a device class other than "pingable".

Option 5. Deep Discovery is compute-intensive and might significantly tax your network if used as the default setting. ScienceLogic recommends that you use this option on a per-discovery basis by selecting it in the Discovery Session Editor page.

Rediscovery Scan Level (Nightly). Specifies the data to be gathered/updated each night during auto-discovery. The auto-discovery process will find any changes to previously discovered devices and will also find any new devices added to the network. The options are the same as for Initial Discovery Scan Level.

ScienceLogic recommends that you delete all unused PowerPacks from your Skylar One system to improve the performance of the nightly auto-discovery process.

Discovery Scan Throttle. Specifies the amount of time a discovery process should pause between each IP address or hostname in a discovery session. (You specify the list of IP addresses or hostnames for a discovery session in the IP Address/Hostname Discovery List field in the Discovery Session Editor page.) Pausing discovery processes between IP addresses or hostnames spreads the amount of network traffic generated by discovery over a longer period of time. 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 Skylar One should scan all IP addresses on a device for open ports. You can override this setting for a single discovery session in the Discovery Session Editor modal page. The choices are:

0. Disabled. Skylar One will scan only the primary IP address (the one used to communicate with Skylar One) for open ports.
1. Enabled. Skylar One will scan all discovered IP addresses for open ports.

Port Scan Timeout. Length of time, in milliseconds, after which Skylar One should stop trying to scan an IP address for open ports and begin scanning the next IP address (if applicable). You can override this setting for a single discovery session in the Discovery Session Editor modal page. Choices are between 60,000 and 1,800,000 milliseconds.

Restart Windows Services (Agent required). Specifies whether Skylar One 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. Skylar One will not automatically restart failed Windows services that have been defined on the device with a startup type of "automatic".
1. Enabled. Skylar One will automatically restart failed Windows services that have been defined on the device with a startup type of "automatic".

Hostname Precedence. Specifies which name Skylar One 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 Skylar One cannot find an SNMP name for the device, Skylar One will assign the name returned by the DNS Reverse Lookup. If Skylar One cannot find a DNS Reverse Lookup name for the device, Skylar One will use the device's Admin Primary IP address as the device name in Skylar One.
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 Skylar One, 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 Skylar One, 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 Skylar One will use the DNS Reverse Lookup name as the device name (see the description of the field Hostname Precedence), this field specifies whether Skylar One will use the fully-qualified domain name or only the hostname for each discovered device. Choices are:

Strip Device Name (Hostname). Skylar One will use only the device name as the DNS hostname for each device.
Use Full Domain Name (FQDN). Skylar One 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 Skylar One 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 Skylar One 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 Skylar One 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 Skylar One 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 Skylar One version 11.2.0 and later, Skylar One completes this field for you.
Component Device Map Update Mode. This field specifies how Skylar One 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, Skylar One 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 Skylar One 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, Skylar One applies an interpolation function that spaces the data at regular time intervals. For example, suppose you have specified that Skylar One should collect interface data every five minutes. However, due to network traffic across the Data Collectors, Skylar One 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, Skylar One 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.

If the "Data Collection: SNMP Collector" process is disabled on the Process Manager page (System > Settings > Admin Processes), this concurrent SNMP collection option is disabled.

Concurrent SNMP Collection is not available in military unique deployments (MUD) or STIG-compliant deployments.

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.

If the "Data Collection: SNMP Collector" process is disabled on the Process Manager page (System > Settings > Admin Processes), this concurrent network interface collection option is disabled.

Concurrent network interface collection is not available in military unique deployments (MUD) or STIG-compliant deployments.

New UI Default. Starting with Skylar One 11.1.0, the new Skylar One 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 Skylar One system was installing using an ISO, the Skylar One user interface is set as the default, but if your Skylar One 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.

If the "Data Collection: PowerShell Collector" process is disabled on the Process Manager page (System > Settings > Admin Processes), this concurrent PowerShell collection option is disabled.

Concurrent PowerShell Collection is not available in military unique deployments (MUD) or STIG-compliant deployments prior to Skylar One 12.5.1.

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 Skylar One 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.
Enable Snippet Framework Collection. If selected, enables Skylar One to process Snippet Framework Dynamic Applications for collection. You can disable Snippet Framework Dynamic Application processing in your Skylar One system by clearing this checkbox.
Enable L2 Topology Collection and Processing. If selected, Skylar One will perform Layer-2 (L2) topology collection and processing for each device that supports it, and then generate topology maps from the discovered L2 relationships.
Enable L3 Topology Collection and Processing. If selected, Skylar One will perform Layer-3 (L3) topology collection and processing for each device that supports it, and then generate topology maps from the discovered L3 relationships.
Enable CDP Topology Collection and Processing. If selected, Skylar One will perform Cisco Discovery Protocol (CDP) topology collection and processing for each device that supports it, and 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 Skylar One, 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 Collection and Processing. If selected, Skylar One will perform Link Layer Discovery Protocol (LLDP) topology collection and processing for each device that supports it, and then generate topology maps from the discovered LLDP relationships.
Enabling a discovered device configured with CDP or LLDP topology in Skylar One will cause the device to provide information on its neighbor. This information only identifies that there is a neighbor device, not which is the parent or the child. This may cause the parent-child relationship to switch, which requires you to manually reverse the issue within the Skylar One user interface. Skylar One allows you to manually build parent-child relationships between specific device categories. For more information, see Defining Parent and Child Devices in the Events manual.
L2: Collect from all VLANs. If selected, Skylar One will perform Layer-2 (L2) topology collection for all virtual local area networks (VLANs) discovered across your system. If not selected, Skylar One performs L2 topology collection for only VLAN 1, which is the default VLAN on most network switches. By default, Skylar One compiles a list of VLANs for which data should be collected. A VLAN is added to the list for collection only if its state is 1 (operational) and its type is 1 (ethernet).
CDP & LLDP Enhanced Custom Attribute. When enhanced topology is enabled for CDP or LLDP, you can select from this drop-down field a device custom attribute that will be used to try to form the relationship.

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 Skylar One user interface, you can configure single instance login using just those fields. However, for the current Skylar One 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 Skylar One Database Server or use SSH to access the Skylar One 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 Skylar One 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, Skylar One 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.
SSL Certificate Purge Timeout. Specifies the number of days after which SSL certificate data will be deleted. The default value is 730 days.
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.
Schedules Purge Timeout. Specifies the number of days after which expired schedules will be deleted. The default value is 730 days.
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 2 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 2 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 Skylar One 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 Skylar One 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. Skylar One 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 Skylar One, 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 Skylar One 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 Skylar One 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 click the icon).
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 click the icon).
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 Skylar One 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 click the icon for the given interface).
Additional Performance Data	Skylar One 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, Skylar One collects this data every 5 minutes.

Data Normalization and Rollup

Skylar One 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 Skylar One rolls up data, Skylar One groups data into larger sets and calculates the average value for the larger set.

Skylar One supports two types of rollup:

Hourly. Groups and averages data that is collected at intervals of 60 minutes or less. Skylar One 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. Skylar One 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.

Skylar One 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 Skylar One normalizes date, Skylar One transforms the data. To transform the data, Skylar One does the following:

For bandwidth data and data from Dynamic Applications of type "Performance", Skylar One 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", Skylar One evaluates presentation formulas. Counter metrics are first transformed into rates before evaluation.

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

When Skylar One rolls up data, Skylar One must normalize that data, as follows:

As a new piece of data is collected by Skylar One, the hourly normalization and daily normalization is calculated. Skylar One 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 Skylar One, 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, Skylar One collects data about file system usage on the device named my_device. As each raw data point is collected, Skylar One normalizes and rolls up the collected data for file system usage for my_device. Skylar One 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 Skylar One 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 (Devices > Classic Devices > wrench icon > Thresholds, or Registry > Devices > Device Manager > wrench icon > Thresholds in the classic user interface).
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 click the icon). 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 Skylar One will send and receive email. Skylar One 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 Skylar One. Skylar One 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 Skylar One 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 Skylar One. This value can be any alphanumeric value, up to 64 characters in length.
Email Gateway. IP address or fully-qualified name of Skylar One's SMTP Relay server. If Skylar One is to send outgoing messages, this field must be defined. Examples of when Skylar One 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 Skylar One SMTP Relay server is the same as the fully-qualified name of the Database Server or All-In-One Appliance.

If Skylar One 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), Skylar One 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, Skylar One 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, Skylar One 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 Skylar One 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 Skylar One, 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 clicks the OK button to agree to the terms and conditions of use for that system.

To add a custom login alert message to Skylar One:

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.

On a STIG system, you can use the Command Line Interface Login Message (STIG only) field on the Login Alert Message page to change the banner text that appears after you sign into an account that has access to the Skylar One command-line user interface. You cannot enter or input HTML code in the text banner.

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, Skylar One will check the account information for that user. If the user's account information includes an email address, Skylar One 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. Skylar One 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, Skylar One 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 Skylar One will not resend an email.

If the user's account information does not include an email address, Skylar One 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 Skylar One 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 Skylar One when an end user selects the I forgot my password option from the Login page.

To define the email message sent by Skylar One:

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, Skylar One 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 Skylar One 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 Security

The Security Settings page (System > Settings > Security) allows you to define and view the status of global security settings for your Skylar One system.

You can define the following global security setting on this page:

Verify TLS Certificates. When this settings is enabled, Skylar One services will validate TLS certificates that are presented to them and reject self-signed certificates. To enable this setting, select the checkbox and click Save.

On this page, you can also view the current status of the Enterprise Key Management Service (EKMS) for your Skylar One system. This service provides strong encryption for Skylar One credentials, and is enabled by default in versions 12.2.0 and later with no additional configuration required.

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 Skylar One 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 Skylar One's ping (round-trip time divided by 2). The default value is 100 ms. When the latency threshold is exceeded, Skylar One generates an event for that device.
System Availability. During polling, Skylar One 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, Skylar One 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. Skylar One 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 Skylar One 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, Skylar One 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, Skylar One 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), Skylar One does not generate events for that file system.

Rollover Percent. For any collected data that uses a 32-bit counter, you can specify how Skylar One 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, Skylar One assumes that the counter has been manually reset or that the two values were collected out of order. Skylar One 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 Skylar One 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), Skylar One concludes that the 32-bit counter rolled over.
For example, if you specified "25" in this field, Skylar One 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, Skylar One concludes that the 32-bit counter rolled over.
When Skylar One determines a counter has rolled over, Skylar One 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 Skylar One 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 Skylar One records a counter value that is lower than the previously collected value and the platform has determined that the value is not a rollover, Skylar One:

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, Skylar One concludes that the data was collected out of order.
When Skylar One determines a data point has been collected out of order, Skylar One 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, Skylar One concludes that the 32-bit counter was manually reset to zero (0). Skylar One 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, Skylar One concludes that the 64-bit counter was manually reset to zero (0). Skylar One 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 > Classic Devices > 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 > Classic Devices > wrench icon) for a device, this field specifies the percentage of packets that must be returned during an availability check for Skylar One 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, Skylar One 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, Skylar One 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 Skylar One purges the component device. When a device is purged, Skylar One 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 Skylar One 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 Skylar One 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", Skylar One 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 Skylar One 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, Skylar One 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), Skylar One uses the value in this field if there is no differing value specified in the Discovery Session Editor page.

During re-discovery (clicking the magnifying glass icon () in the Device Properties page), Skylar One 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 Skylar One user interface) for the device.

During nightly auto-discovery (run automatically by Skylar One every night, to update device information), Skylar One 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 Skylar One user interface) for a device.

Maximum Allowed Interfaces. Specifies the maximum number of interfaces per device. If a device exceeds this number of interfaces, Skylar One 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), Skylar One uses the value in this field if there is no differing value specified in the Discovery Session Editor page.
During re-discovery (clicking the magnifying glass icon () in the Device Properties page), Skylar One 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 Skylar One user interface) for the device.
During nightly auto-discovery (run automatically by Skylar One every night, to update device information), Skylar One 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 Skylar One user interface) for a device.

Inbound Message Throttle Thresholds. Specifies the maximum number of messages that can be received before Skylar One 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.

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 Skylar One should monitor an interface, Skylar One will collect data about the interface and also monitor performance thresholds for the interface. Skylar One 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, Skylar One 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, Skylar One triggers an event.
For thresholds that include the word Falling, when a value falls below the specified value, Skylar One triggers an event.
For thresholds that do not include the word Rising or Falling, when a value exceeds the specified value, Skylar One 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 Skylar One. 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 Skylar One. 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 Skylar One. 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 Skylar One 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 Skylar One appliance or use SSH to access the Skylar One appliance.
Open a shell session on the server.
Type the following at the command line:

sudo visilo

For ISO installs of Skylar One 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.

Data Pull settings are frequency-specific with Skylar One version 12.3.0. To apply a setting to a specific frequency of Data Pull prepend lf_, mf_, or hf_ to the original setting name for low, medium, and high frequency Data Pull respectively.

If a frequency-specific setting exists, it will take precedence over any generic value for the same setting.

The following two examples show this precedence:

Example 1

An /etc/silo.conf file setting mf_num_storage_procs to 10 while the low frequency and high frequency settings are set to 8 through the generic setting.

[DATA PULL]

num_storage_procs = 8

mf_num_storages_procs = 10

Example 2

An /etc/silo.conf file setting individual frequency memory limits along with Example 1 storage process settings.

[DATA PULL]

num_storage_procs = 8

mf_num_storages_procs = 10

lf_memory_limit = 1073741824

mf_memory_limit = 4294967296

hf_memory_limit = 2147483648

eventmanager. You can edit this setting in the silo.conf file on each Skylar One 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 Skylar One 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 Skylar One 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 Skylar One, 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, Skylar One 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 Skylar One 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 Skylar One 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 Skylar One, 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. Skylar One 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 Skylar One 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 Skylar One 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 Skylar One 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 Skylar OneDatabase Server.

Disabling the User Interface on a Database Server

Database Servers are automatically configured to provide the user interface. If your Skylar One 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