IT Monitoring for Networks, Applications, Virtual Servers and the Cloud
IT Monitoring for Networks, Applications, Virtual Servers and the Cloud
Nagios® Core configuration files are recreated at every Opsview Monitor reload. The files are generated from the
Most Opsview Monitor 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 default 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
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.
These control how Opsview Monitor 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 Monitor 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 127.0.0.1 to force the dbport to be used.
This Variable controls the number of parallel jobs that the Opsview Monitor reload process will use. This defaults to four, 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 before deleting them.
This is the shared secret used by Opsview Monitor'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:
#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
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 0.0.0.0 (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 127.0.0.1, which is used by slaves in a distributed environment. Set to 0.0.0.0 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 Monitor 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 Monitor. This defaults to 2 (DES).
This sets the cache expiry time for Service Check results on all slaves, in seconds.
The default is five minutes.
Note: To take effect, you must initiate an Opsview Monitor reload and then restart Opsview Monitor on the slaves with
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 Monitor.
This is a shared password between the NRD server (running on the Opsview Monitor 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 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
If a variable is stored in
nagios.cfg then the override needs to be
You need to set all the values together. For instance:
$overrides = <<'EOF'; nagios_service_check_timeout=120 nagios_max_concurrent_checks=50 nagios_enable_notifications=0 nagios_retained_host_attribute_mask=14 nsca_max_packet_age=20 nagios_status_update_interval=30 nagios_temp_file=/tmp/nagios.tmp EOF
This would change
max_concurrent_checks, enable_notifications and retained_host_attribute_mask in
nagios.cfg and max_packet_age in
Further information on Nagios Core configuration can be found
Note: Be aware that changing some options may adversely affect the performance of Opsview Monitor.
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 one 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.
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.
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 Monitor. You can ignore the IP address (internally, it will set the IP to 0.0.0.0). Add to the opsview_web_local.yml file:
Controller::Root: authtkt_ignoreip: 1
Note: if you change this, you will also need to update the Apache configuration file so that the following is set:
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:
The default value is max_servers of 5.
Add to the opsview_web_local.yml file:
ProductionEngine: max_servers: 20
The smallest setting you can use is:
ProductionEngine: max_servers: 3 min_servers: 2 max_spare_servers: 1 min_spare_servers: 1
session: expires: 86400
host_interfaces: default_throughput_critical: 55% default_throughput_warning: "" default_errors_critical: 20 default_discards_critical: 5
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:
Controller::Root: show_license_messages: ADMINACCESS
show_license_messages is set to 1 which means
all users will see it. If set to 0, this disables all license messages.
Otherwise, it expects a string to mean which particular
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.
Although Opsview Monitor 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: