The LOAD settings can be accessed at Configuration > System > Load Configuration and offer a wide set of advanced system settings which apply to:

Monitor process behavior after reload
Creation of auto backups
Creation of support files

On this page:

Settings

The following table explains all settings in detail.

The Defaults for these settings differ depending on the underlying device. You can easily reset the defaults by choosing just below the heading Load Configuration.

Setting	Description
Log entries time frame in days word_to_avoid_word_wrap_bug_confluence	Specifies for how many days the logfiles will be included in the log rotation, before it'll be purged. Note that this can increase the disk usage easily.
Event Log Options	Select what shall be included in the Event Log (event.log) Log Notifications Log Service Retries Log Host Retries Log Event Handlers Log Initial States Log External Commands Log Passive Checks
Load Warning Threshold	Threshold for the system load, you can check the current load in *Administration Web Interface* > Status > System > Performance
Load Critical Threshold	Threshold for the system load, you can check the current load in *Administration Web Interface* > Status > System > Performance
CPU Warning Threshold	Threshold for the percentual CPU usage, you can check the current load in *Administration Web Interface* > Status > System > Performance
CPU Critical Threshold	Threshold for the percentual CPU usage, you can check the current load in *Administration Web Interface* > Status > System > Performance
PROCS Warning Threshold	Threshold for the number of processes running at a time, an alert will be shown in service check -azeti-A- > PROCS
PROCS Critical Threshold	Threshold for the number of processes running at a time, an alert will be shown in service check -azeti-A- > PROCS
RRD disk usage Warning Threshold (Gb):	Thresholds for the overall disk usage of the RRD files, which hold all collected performance data, an alert will be shown in service check -azeti-A- > RRD-Disk-Usage
RRD disk usage Critical Threshold (Gb)	Thresholds for the overall disk usage of the RRD files, which hold all collected performance data, an alert will be shown in service check -azeti-A- > RRD-Disk-Usage
Send Warning Notification	Specifies if a notification in case of any WARNING or CRITICAL alert of the above mentioned metrics should be sent. This requires enabled notifications and proper SMTP settings.
Send Critical Notification	Specifies if a notification in case of any WARNING or CRITICAL alert of the above mentioned metrics should be sent. This requires enabled notifications and proper SMTP settings.
Service interleave factor *	This variable determines how service checks are interleaved. Interleaving allows for a more even distribution of service checks, reduced load on remote hosts, and faster overall detection of host problems. Setting this value to 1 is equivalent to not interleaving the service checks (this is how versions of Nagios previous to 0.0.5 worked). Set this value to s (smart) for automatic calculation of the interleave factor unless you have a specific reason to change it. The best way to understand how interleaving works is to watch the status CGI (detailed view) when Nagios is just starting. You should see that the service check results are spread out as they begin to appear. x = A number greater than or equal to 1 that specifies the interleave factor to use. An interleave factor of 1 is equivalent to not interleaving the service checks. s = Use a "smart" interleave factor calculation (default)
Service Inter check delay method *	This option allows you to control how service checks are initially "spread out" in the event queue. Using a "smart" delay calculation (the default) will cause Nagios to calculate an average check interval and spread initial checks of all services out over that interval, thereby helping to eliminate CPU load spikes. Using no delay is generally not recommended unless you are testing the service check parallelization functionality. Using no delay will cause all service checks to be scheduled for execution at the same time. This means that you will generally have large CPU spikes when the services are all executed in parallel. More information on how to estimate how the inter-check delay affects service check scheduling can be found here.Values are as follows: n = Don't use any delay - schedule all service checks to run immediately (i.e. at the same time!) d = Use a "dumb" delay of 1 second between service checks s = Use a "smart" delay calculation to spread service checks out evenly (default) x.xx = Use a user-supplied inter-check delay of x.xx seconds
Host Inter check delay method *	This option allows you to control how host checks that are scheduled to be checked on a regular basis are initially "spread out" in the event queue. Using a "smart" delay calculation (the default) will cause Nagios to calculate an average check interval and spread initial checks of all hosts out over that interval, thereby helping to eliminate CPU load spikes. Using no delay is generally not recommended. Using no delay will cause all host checks to be scheduled for execution at the same time. Values are as follows: n = Don't use any delay - schedule all host checks to run immediately (i.e. at the same time!) d = Use a "dumb" delay of 1 second between host checks s = Use a "smart" delay calculation to spread host checks out evenly (default) x.xx = Use a user-supplied inter-check delay of x.xx seconds
Service reaper frequency in seconds *	This option allows you to control the frequency in seconds of check result "reaper" events. "Reaper" events process the results from host and service checks that have finished executing. These events consitute the core of the monitoring logic in Nagios.
Max Reaper Time in seconds *	This option allows you to control the maximum amount of time in seconds that host and service check result "reaper" events are allowed to run. "Reaper" events process the results from host and service checks that have finished executing. If there are a lot of results to process, reaper events may take a long time to finish, which might delay timely execution of new host and service checks. This variable allows you to limit the amount of time that an individual reaper event will run before it hands control back over to Nagios for other portions of the monitoring logic.
Retention file update interval in minutes *	This setting determines how often (in minutes) that Nagios will automatically save retention data during normal operation. If you set this value to 0, Nagios will not save retention data at regular intervals, but it will still save retention data before shutting down or restarting.
Max concurrent checks *	This option allows you to specify the maximum number of service checks that can be run in parallel at any given time. Specifying a value of 1 for this variable essentially prevents any service checks from being run in parallel. Specifying a value of 0 (the default) does not place any restrictions on the number of concurrent checks. You'll have to modify this value based on the system resources you have available on the machine that runs Nagios, as it directly affects the maximum load that will be imposed on the system (processor utilization, memory, etc.).
Max check spread time in minutes *	This option determines the maximum number of minutes from when Nagios starts that all services (that are scheduled to be regularly checked) are checked. This option will automatically adjust the service inter-check delay method (if necessary) to ensure that the initial checks of all services occur within the timeframe you specify. In general, this option will not have an affect on service check scheduling if scheduling information is being retained using the use_retained_scheduling_info option. Default value is 30 (minutes).
Status update interval in seconds *	Determines after how many seconds the global status file should be updated. Increase this to achieve faster alert appearance, especially when using time critical checks like MODBUS dry contact checking or access control.
Use RAM Disk for Status	Saves the status data in a RAM disk if enabled. Disabling this option is recommended for large installations where status data files may reach large sizes.
Enable Environment Macros	Set environment variables and macros for runtime components like plugins, event handlers, notifications and the like. Disable this option if you're not sure if you use these macros. Disabling it increases performance and avoids higher latencies.
Use Large Installation Tweaks	Allows monitoring process to use different shortcuts in order to increase performance and avoid higher latencies and it disables the automatic backup creation upon reboot. Set this option during upgrades and maintenance works where reboots are required as it avoids the autobackup creation upon boot and speeds up the boot process. This option is highly recommended for most installations and can be safely activated.
Monitoring Debug Level	Enable this for detailed debug information of the monitor process. This should only be enabled for troubleshooting and is considered for experts. Leave it disabled if not otherwise advised. If enabled you can see debug information in the log file Administration Web Interface > Status > Logs > Monitor Process (Debug) [daaz_debug.log]. Choose which details shall be included in the log, the more you enable the more system resources are required for logging and the more it is likely for the log file to get flooded. Function enter/exit information Config information Process information Scheduled event information Host/service check information Notification information Event broker information
Enable Support File Creation	Enables the creation of support files in the background every minute. This is intended for troubleshooting and investigation. The support files can then be downloaded in Status > Summary > Click here to create support file archive
Maximal Number of Support Files	Specifies the number of files which shall be created every minute, so if 60 is specified the SONARPLEX would create files for the last hour.

Settings marked with an * were taken from the official Nagios 3.0 Documentation to which azeti SONARPLEX is fully compatible. See ww.nagios.org for further details. Nagios is a registered trademark by Ethan Galsted.