Common Tasks

Below is a list of some of the common tasks System Administrators may need to perform.

Backing up Opsview Monitor databases and configuration

Edit /opt/opsview/coreutils/etc/opsview.conf to check or set the correct backup destination in the variable $backup_dir.

 su - opsview
 /opt/opsview/coreutils/bin/rc.opsview backup

Backing up Opsview Monitor database only

Ensure opsview.conf is correct:

su - opsview
/opt/opsview/coreutils/bin/db_opsview db_backup | gzip -c > {backup file}

The runtime, odw, and reports databases may be backed up in the same way.

Restoring from a database backup

Identify the required image to restore from (location is held in $backup_dir variable within the opsview.conf file if using a full backup rather than database only).

su - opsview
gunzip -c {/path/to/opsview-db-{date}.sql.gz} | /opt/opsview/coreutils/bin/db_opsview db_restore

If you need to upgrade the database schema because you have restored a backup from an earlier release of Opsview, you can run the following:



Once the restore has completed, you should Apply Changes to Opsview.

Setting MySQL root password

We recommend you set a password for root user:

mysqladmin -u root password {password}

Granting access to remote user

For making remote database connections to Opsview Data Warehouse:

grant all privileges on *.* to '<username>'@'<hostname>' identified by '<password>' with grant option;
flush privileges;

Fixing damaged database tables

If a database table is damaged, you may get error messages like:

Table 'service_saved_state' is marked as crashed and should be repaired

A common cause is running out of space on /var partition where mysql writes its table files:

mysqlcheck -p -u <user> <database>

To repair table (from MySQL client - you will need enough disk space free for MySQL to make a new copy of the damaged table as a .TMD file):

use <database name>;
REPAIR TABLE <tablename>;

To check all databases, you can use the following as the mysql root user:

mysqlcheck -A -r -u root -p

Using a read-only database

Opsview has the ability to use a separate, read-only replicated database, for certain REST related database queries. This will, for the most part, increase the responsiveness of the main REST API calls that Dashboard uses, and reduce the load on the master database.

This relies on MySQL replication to keep the data in sync between the master and its collectors. See MySQL documentation on how to setup MySQL replication.

To avoid unnecessary replication on a MySQL slave system, you should add the following parameter to the collector my.cnf:

replicate-wild-ignore-table = %.%_noreplicate

To configure Opsview, we need to allow Opsview Web to connect to the replicated database.

For example:

CREATE USER 'opsview'@'masterserver' IDENTIFIED BY 'password';
GRANT SELECT ON opsview.* TO 'opsview'@'masterserver';

The /opt/opsview/coreutils/etc/opsview.defaults has database related ‘ro’ variables. Copy these to opsview.conf and change them to point to the slave MySQL server.

Any variables that are not copied into opsview.conf or changed will default to their respective values from the non-read-only database. Be sure to double-quote the variable values (see the other database related values around that area in opsview.defaults for some examples).

You can obtain the encrypted versions of the passwords by running /opt/opsview/coreutils/bin/opsview_crypt.

Restart opsview-web: ‘service opsview-web restart’. Dashboard and other parts of Opsview Monitor should now be using the collector MySQL database for most status views.


If Opsview Monitor does not start back up after a restart, check that you’ve changed the values of the correct _ro_ variables in opsview.conf.

["Opsview"] ["User Guide"]

Was this topic helpful?