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
To restore a full backup of Opsview Monitor, identify the required image to restore from. The location of the image is stored in the $backup_dir
variable in the opsview.conf
file.
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 such as:
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.
- Here, we assume you have already replicated at least the opsview and runtime databases.
- Ensure that the opsview user exists on the slave MySQL database server.
- 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';
The /opt/opsview/coreutils/etc/opsview.defaults
has database related _ro_
variables. Copy these to the opsview.conf
file, and then change them to point to the slave MySQL server.
Any variables that you do not copy into opsview.conf
or change will keep their default values from the non-read-only database. Be sure to enclose the variable values in double quotes (see the other database-related values in opsview.defaults
for examples).
You can obtain the encrypted versions of the passwords by running /opt/opsview/coreutils/bin/opsview_crypt
.
Restart opsview-web
:
/opt/opsview/watchdog/bin/opsview-monit restart opsview-web
The dashboard and other components of Opsview Monitor are using the collector MySQL database to display most status views.
Troubleshooting
If Opsview Monitor does not start the backup process after a restart, ensure that you have changed the values of the correct _ro_
variables in the opsview.conf
file.