Welcome to docs.opsview.com

Configuration Files

Configurable Values: opsview.conf

Nagios® Core configuration files are recreated at every Opsview reload. The files are generated from the nagconfgen.pl script.

Most Opsview configuration is performed via the web user interface. However some less common options are located in configuration files.

Opsview's main configuration file is /usr/local/nagios/etc/opsview.conf. The defaults file is /usr/local/nagios/etc/opsview.defaults and may be changed in future upgrades. The opsview.conf file will not be touched.

The configuration takes the opsview.defaults variables and overlays the opsview.conf contents.

If you want to make any changes, edit opsview.conf. You must end the file with:


Verify the configuration with:


This should return a subset of the variables in the file.

Database options

  • $db
  • $dbuser
  • $dbpasswd
  • $dbhost
  • $dbport

These control how Opsview connects to its databases. There are four sets of these variables, the other three prefixed with “runtime_”, “odw_”, and “dashboard_” to communicate to Runtime, ODW (Opsview Data Warehouse) and Dashboard respectively. db is the database name, and usually should not be changed.

Restart Opsview and Opsview Web after changing these variables.

Note: If the dbhost is set to 'localhost', MySQL will connect via a file socket - not via an IP socket - and thus the dbport will be ignored. You will need to set dbhost to be to force the dbport to be used.


This variable controls the number of parallel jobs that the Opsview reload process will use. This defaults to 4, but can be increased if you have lots of slave systems and multiple CPUs on your master server. Note: this only helps per slave, not per node within a slave cluster.

The output from the reload process is available in /usr/local/nagios/var/log/create_and_send_configs.debug file. This explains where the most time is being used during the reload


This is the amount of time to leave untouched RRD files (for performance data, MRTG or NMIS) before deleting them.


This is the shared secret used by Opsview's authentication system. This secret can be passed to other applications (such as Nagvis) if you want single sign on ability.

You can also use an encrypted value for the shared secret by setting the variable $authtkt_shared_secret_encrypted instead. Use the opsview_crypt tool to generate the encrypted value.

You must restart Opsview Web for this to take effect.

Note: If you change this, you must update the key for all your SSO systems, including your Apache configuration file:

TKTAuthSecret "shared-secret-please-change"
#TKTAuthSecretEncrypted "encrypted-value" # Use this if you want to use the encrypted value instead

If this secret is changed and your browser still has the old auth_tkt, then you will get an error in the Opsview login page that says “Invalid authentication ticket”.


If you have slaves setup, you can have them in reverse SSH mode, which means that the slave initiates the SSH connection to the master, who can then communicate via this tunnel.


To allow slave initiated setups, you have to have a base port number and the slave will be contactable via the base port number + their cluster node id. So choose a range which will not be used by anything else.


This defines the bind address for the opsview_web_server process. This defaults to (all interfaces), but you can set to a specific interface if you prefer.


This defines the server address for the nsca daemon on the master server. This defaults to, which is used by slaves in a distributed environment. Set to if you want to listen on all interfaces so you can pass passive results to the master.


This is a shared password between the NSCA server (running on the Opsview master) and all slaves. This value is auto generated on an install.

If you change the value, you must do a reload (to generate the configuration files that NSCA uses) and then you have to run /etc/init.d/opsview restart on the master and all slaves to take effect.


This sets the encryption (send_nsca.cfg) and decryption method (nsca.cfg) when the configuration files are generated by Opsview. This defaults to 2 (DES).


This sets the cache expiry time for service check results on all slaves, in seconds.

The default is 5 minutes.

Note: To take effect, you must initiate an Opsview reload and then restart Opsview on the slaves with /etc/init.d/opsview restart.

Note: In the case of a connection failure between a slave and the master, more disk space will be used to cache the results. Results will be dropped as they go over the cache period. Ensure you have sufficient space to store results for your full cache period.

Note: Results will be processed in sequential time order on the master server and may not integrate into the Opsview Master if the time between the result and current time is too old. We recommend you do not use a value above 30 minutes.


This sets whether to delay the ODW import if all slaves are not OK.


This is deprecated as NRD is the only supported slave communication mechanism. An NSCA daemon will be running for any NSCA clients that may need to connect to Opsview.


This is a shared password between the NRD server (running on the Opsview master) and all slaves. This value is auto generated on an install.

If you change the value, you must do a reload (to generate the configuration files that NRD uses) and then you have to run /etc/init.d/opsview restart on the master and all slaves to take effect.


This is the amount of time that SNMP trap exceptions are kept in the database. This defaults to 60 days.


This sets whether graphs display the legends by default.


This sets the value where a popup will appear on graph pages if there are more metrics than this number. By default this is 10.


This sets the number of MRTG forks that can run concurrently. Defaults to 8.


This is a Nagios file that gets continually written to. For performance reasons, you can change this location to a RAM disk.

Note that you will need to restart Nagios for this change to take effect as a reload is not sufficient. This will also affect slave servers.

If you change this to a different file system, you must also change the temp_file location as well. The status_dat file is written to the temp_file location first and then moved into status_dat location.

To change the temp_file location, use the $overrides option below. You may also want to change the frequency of writing the status_dat file.


This variable overrides values in the generated nagios.cfg, cgi.cfg and nsca.cfg files.

If a variable is stored in nagios.cfg then the override needs to be prefixed with nagios_, if the variable is stored in cgi.cfg then the override needs to be prefixed with cgi_, and so forth.

You need to set all the values together. For instance:

$overrides = <<'EOF';

This would change max_concurrent_checks, enable_notifications and retained_host_attribute_mask in nagios.cfg,use_authentication in cgi.cfg and max_packet_age in nsca.cfg.

Further information on Nagios Core configuration can be found here.

Note: Be aware that changing some options may adversely affect the performance of Opsview.

Note: If you change Nagios values, be aware that Nagios may use values based on the last retained values in the retention.dat file. For example, even if nagios_enable_notifications is set to 1 in the overrides, Nagios will use the value from retention.dat instead. If you need to disable notifications globally, use the UI screens in Settings ⇒ Monitoring Engine ⇒ Disable Notifications instead.

Configuration Options: Opsview Web

Opsview Web uses the file /usr/local/opsview-web/opsview_web.yml as its main configuration file. Local changes can be made in /usr/local/opsview-web/opsview_web_local.yml and these will be retained over an upgrade.

Changes to these files require a restart of Opsview Web.

Authtkt Ignore IP

When generating the authtkt key, the browser IP address is added into the mix. However, in some scenarios, you may not want this - for instance, if you have multiple proxies in front of Opsview. You can ignore the IP address (internally, it will set the IP to

Add to the opsview_web_local.yml file:

  authtkt_ignoreip: 1

Note: if you change this, you will also need to update the Apache configuration file so that the following is set:

TKTAuthIgnoreIP on

Starman Server Processes

Opsview Web uses Starman via Catalyst to server dynamic pages. You can increase the number of Starman server processes to improve web responses, at the cost of using more memory.

You can estimate the amount of memory used by Starman with the following calculation:

  • max_servers x 200MB

The default value is max_servers of 5.

Add to the opsview_web_local.yml file:

 max_servers: 20

The smallest setting you can use is:

  max_servers: 3
  min_servers: 2
  max_spare_servers: 1
  min_spare_servers: 1

Login Timeout

You can modify the following to increase or decrease the time that the interface automatically logs you out.

 expires: 86400

Default Thresholds for Host Interfaces

You can add the following to change the default host interface thresholds:

  default_throughput_critical: 55%
  default_throughput_warning: ""
  default_errors_critical: 20
  default_discards_critical: 5

License Messages

If your license for Opsview Pro or Opsview Enterprise is coming up for renewal, there will be a banner that is displayed in the top of all Opsview screens.

You can change the access required to see this message by changing the configuration file to:

  show_license_messages: ADMINACCESS

By default, show_license_messages is set to 1 which means all users will see it. If set to 0, this disables all license messages. Otherwise, expects a string to mean which particular access level is required to display the banner - this can be a comma separated list and thus any one of those accesses will have the banner displayed.

Note: If you disable banner messages, ensure the service check Opsview License Checks is running and that notifications work, so that you still get warnings about upcoming expiry.

Temporarily Changing Nagios Core Configuration Values

Although Opsview will regenerate the Nagios Core configuration files on every reload, you can temporarily change the Nagios Core configuration files if you want to test something quickly for the Nagios Core daemon.

The process is:

  • Make changes to the files you want
  • Run a verification step: /usr/local/nagios/bin/rc.opsview check
  • Reload Nagios: /usr/local/nagios/bin/rc.opsview reload