NAME

Vipaka - Configuration Guide


DESCRIPTION

This guide will help you step through the process of editing the vipaka.conf configuration file to control the behavior of Vipaka.


Installing a read-only user in your database

Vipaka needs to be able login to your target databases in order to monitor them.

Vipaka is completely read-only. If you're concerned about Vipaka making changes in your database, create a read-only user for it to login as. The supplied script $VIPAKA/sql/vipaka_user.sql will do just that. Examine the script, then login as sys, and run it like this (we're assuming here that you've cd'd into the ``sql'' directory:

SQL> @vipaka_user.sql

Enter value for vipaka_password: akapiv

User created.

Grant succeeded.

Grant succeeded.

You can now use this user and the password you specified when configuring a vipaka.conf file.

click here for details


Basic Editing of the vipaka.conf file

The vipaka.conf file is the core configuration file for vipaka. Eventually it will be updatable via a web front-end, Currently one must edit the file by hand.

The 'vipaka' line is a directive to vipaka of a database it needs to monitor.

vipaka:*:VENUS:vipaka:akapiv vipaka:*:MARS:vipaka:akapiv

In this case vipaka will monitor the VENUS and MARS databases. The last two parameters are the username and password to login with. 'MARS' and 'VENUS' must be defined in the tnsnames.ora file otherwise an error will be returned.

The format of most other lines in this file are:

SERVICE:X:Y:Z

The SERVICE can be one of these:

redologs rollback tablespaces slowsql hitratios fragmentation extents latch mts repqueue reperror

X - how often (in minutes) to monitor this info Y - warning threshold Z - alert threshold

A service is not monitored if it's time column is 0, or it is commented out with the # character, or if it is not in the file at all. For repeated entries, the last one listed will be used.

A very simple configuration would look like this:

redologs rollback tablespace slowsql hitratios fragmentation extents latch

In this case, the factory defaults for X, Y, and Z will be used. Conversely, set your own values:

tablespace:15:85:95

Which directs vipaka to check up on tablespace quotas every 15 minutes, flagging a warning if they are 85% full, or an alert if they are 95% full.


Editing the vipaka.conf using Preference Groups

By default vipaka uses a default preference group. That's what the '*' is for in the second field. It can also be blank, or the word default:

vipaka:*:MARS:vipaka:akapiv vipaka::MARS:vipaka:akapiv vipaka:default:MARS:vipaka:akapiv

All three achieve the same result. However, one can break the preference settings up into groups. These are given case sensitive names in this vipaka line, and vipaka then looks for config lines later in the file, PREPENDED with this name.

vipaka:New York:MARS:vipaka:akapiv New York:tablespace:10:80:90 New York:slowsql New York:hitratios:2:85:95

Notice that the exact spelling is relevant here. Case is checked, as well as spaces. In fact, any characters between the colons matter.

For more information on configuring services, see the services documentation

here

.


Email Notification

Email notification is an important part of any monitoring app. In it's most basic form, you add a line in your config file like this:

notify_email:full:shull,root,oracle@somewhere.com,nobody@xyz.com

The first field is obviously the directive. The second can be 'full' or 'short'. The 'short' format email is a very limited message suitable for text pagers which often have an 80 character limitation. The third field is a comma delimited list of email addresses.

Check the various *.conf files in the main directory.


Using the vipakactl utility

The vipakactl utility enables you to manage a running vipaka daemon. You can use it to stop or start the daemon, get status on a running daemon, reread the config file or force a refresh of all services.

To get help do $ perldoc vipakactl or the following:

$ bin/vipakactl -h

-h print help and exit -v print version and exit -w print warranty and exit -s start vipakad daemon -p stop vipakad daemon -t print status of running vipakad daemon -r reload karam.conf config file -i specify process id (if lock file is missing) -l specify logfile for vipakad (ignored if not starting vipakad) -c specify vipaka config file (ignored if not starting vipakad) -k specify vipaka doc_root -d delete dynamically created vipaka files (vipaka.html, info/*.html)

vipakactl [-h|-v|-w|-s|-p|-t|-r|-d] [-l file] [-c file] [-k dir]

Get the status of a running vipaka daemon as follows:

$ bin/vipakactl -s Starting vipaka daemon...

$ bin/vipakactl -t vipakad started at 19:46 pid:2853 Using EMAIL for notification DB:AEON UP, Prefgroup:default - services: 19:46 -- mts 19:46 OK tablespace 19:46 OK slowsql 19:46 OK up 19:46 WARN hitratios 19:46 OK rollback 19:46 OK extents 19:46 OK latch 19:46 OK redolog 19:46 OK fragmentation