System Preferences

This is the web server for accessing the web interface of Opsview.

If this field has not been saved before, the field will be automatically populated based on the URL.

At reload time, if this system preference has not been saved, Opsview will use the master server's hostname (or IP).

This controls the default value for whether to show the time line when the page first loads in the Events view.

This refers to the default layout of the Network Map.

• Depth Layers
• Collapsed Tree
• Balanced Tree (default) - display the master server in the middle of the page with all parent/child relationships beneath
• Circular - the master server is in the middle of the page with all parent child relationships linked radially, with distance related to the number of relationships between a host and the master server
• Circular (Marked Up) - see Circular, but also includes clearer markings for distance from master server

The refresh rate / refresh interval field specifies how frequently (in seconds) pages within the Opsview GUI will automatically refresh. A page refresh can be performed manually by clicking the refresh button within the Opsview GUI.

Specifies how long in days that the audit logs are kept for. If you set this to 0, logs will never be removed.

The tables pruned based on this variable in runtime are:

• nagios_contactnotificationmethods
• nagios_contactnotifications
• nagios_notifications
• nagios_statehistory
• nagios_commenthistory
• nagios_acknowledgements
• nagios_flappinghistory
• nagios_downtimehistory
• nagios_eventhandlers

These tables are pruned of data older than 7 days. See ODW if you wish to retain the data over a longer period.

• nagios_servicechecks
• nagios_hostchecks

These tables are pruned of data older than 7 days. It is only used for debugging purposes:

• nagios_conninfo

The housekeeping job runs overnight.

From Opsview 3.11.1.

If a host template is removed from a host, via the host edit page or the host template edit page, then if this flag is set, then any appropriate host specific monitors will be removed unless the host monitor is also referenced in another host template that this host has.

For example, assume hostA has two host templates, Unix Base and Unix Backup. The Unix Base host template has two service checks, Loadavg and Memory. The Unix Backup host template has Loadavg only. The host also has two host exceptions for both Loadavg and Memory.

If hostA has the Unix Base host template removed, then if this flag is set, the host exception for Memory is removed. If it was not removed, then on an reload, Memory would be created as a service because it is still referenced as a host specific monitor. Note that Loadavg would not be removed because it is still referenced in the Unix Backup host template.

The default value for this is on as this is a useful behaviour.

URL constructed using macros to use instead of the default wiki information pages, specifically for hostgroup information.

Available macros are:

• $HOSTGROUPNAME$ - name of hostgroup

URL constructed using macros to use instead of the default wiki information pages, specifically for host information.

Available macros are:

• $HOSTADDRESS$ - primary hostname/IP of the host
• $HOSTNAME$ - title of the host

URL constructed using macros to use instead of the default wiki information pages, specifically for service information. This is available from version 3.13.1.

Available macros are:

• $HOSTADDRESS$ - primary hostname/IP of host
• $HOSTNAME$ - title of the host
• $SERVICENAME$ - name of service
• $SERVICECHECKNAME$ - name of service check

Enter a URL to your Netdisco instance. It should be of the form:

http://server.example.com/netdisco

A link will be added to Netdisco on the Host Interface page.

You can also search a device on your Netdisco instance if you type in the Search Host box: nd hostname.

This option controls whether you will get alerts about new major Opsview releases.

You will always get an alert about any minor versions that have been released (eg, you are currently on 3.2.2 and 3.2.3 is released).

However, if this flag is set, you will also get an alert when 3.4.0 is released. If the flag is not set, you will only get alerts about minor releases for your existing version.

More information is available at the check updates page.

Note: This flag is only available on Enterprise editions of Opsview. Because older Community editions are deprecated as soon as a newer Community edition is available, you will always get alerted about major releases. This option was still available in Opsview 3.3.0, but is removed from 3.3.1 onwards.

This flag determines whether Opsview sends anonymous information about your system to our central server.

You can click on the Show Survey Information for Your System button to show what data would be sent back.

More information can be found at the Opsview System Survey page.

This field is no longer available from Opsview 3.7.0. See Notification Methods instead.

Note: These screens changed in Opsview 3.9.1

This option controls whether ODW will be populated with events and statistical data.

If selected, a summary of the previous hour's data will be imported at 4 minutes past every hour.

The import will populate the following tables in ODW:

• downtime_host_history
• downtime_service_history
• acknowledgement_host
• acknowledgement_service
• state_history
• notification_host_history
• notification_service_history
• service_availability_hourly_summary
• performance_hourly_summary

This value is used by the nightly housekeeping to determine how many months of data are to be retained for the standard data.

If you set to 0, then the table will not be trimmed. However, you will need to put some procedures in place to archive the data away regularly - for instance, if you have mysql partitioning enabled, you may want to drop a whole partition at a time instead of running a DELETE.

This option controls whether extended data is stored in the ODW database. This means every service check result and every performance data plot will be stored.

This will populate the following tables in ODW:

• servicecheck_results
• performance_data

Note: This is likely to use a lot of space in ODW.

This value is used by the nightly housekeeping to determine how many months of data are to be retained for the extended data.

If you set to 0, then the table will not be trimmed. However, you will need to put some procedures in place to archive the data away regularly.

Note: This retention period does not affect the RRD data storage or other disk files.

Change the general date format.

This option determines whether or not Nagios® Core will use soft service state information when checking service dependencies. Normally Nagios Core will only use the latest hard service state when checking dependencies. If you want it to use the latest state (regardless of whether its a soft or hard state type), enable this option.

You can define dependencies in the service check configuration.

Logs when a notification is sent out. Useful.

Logs when an event handler script is invoked. Useful.

Logs when a service is in a soft failure state. Useful, especially when debugging event handlers.

Logs when a host is in a soft failure state. Useful, especially when debugging event handlers.

This logs every passive check into the Nagios Core log file. This value will affect the master and slave servers.

Note: In a distributed environment, this will produce a large number of log entries on the master. Only switch on for short periods of time.

Used for debugging if you find that Nagios Core unexpectedly crashes.

Core dumps will be written to the nagios user's home directory. Check that the nagios user can write to their home directory and that ulimit -c is not zero.

If you see the following in the nagios.log file:

[1274862094] Caught SIGSEGV, shutting down...

Then a core dump will not be produced, because the nagios daemon would have handled a SIGSEGV signal, instead of allowing the OS to produce a core dump.