Common Tasks
A list of common tasks that SysAdmins may need to perform
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.
Updated about 3 years ago