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:

 /opt/opsview/coreutils/installer/upgradedb_opsview.pl

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 - note that you'll 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 external 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. Here, we assume you have already replicated at least the opsview and runtime databases. You'll need to make sure that the opsview user exists on the slave MySQL database server, and have SELECT access to the opsview and runtime databases, respectively. You should allow them to connect from the Opsview Monitor master database server.

For example:

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

/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 aren't 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.

Troubleshooting

If Opsview Monitor doesn't start back up after a restart, check that you've changed the values of the correct 'ro' variables in opsview.conf.