#---------------------------------------------------------------
#
# karma.conf
#
# this file configures the karma Oracle database monitoring
# utility.  Hopefully this will eventually be updatable
# via a web front-end.
#
# The format of most lines in this file is:
#
# SERVICE:X:Y:Z
#
# SERVICE can be one of these: redologs, rollback, tablespaces, 
# slow_sql, alert_log, hit_ratios, fragmentation, extents,
# latch, mts.  X is the interval to check this service, Y
# is the warning level, and Z is the alert level.
#
# 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.
#
#
# NOTIFICATION
#
# prefname:level:interval:service1,service2...
#
# Prefname specifies a perference group, level is one of (notify_alert
# notify_warn), interval is how often to send notification,
# short or long is the size of the message.  Use short for 
# a text pager.  After that is just a list of services.
# Note also that you'll need a "notify_email" line to specify
# email addresses, otherwise the message will have nowhere to 
# go.  It looks like this:
#
# prefname:notify_email:full|short:shull,root
#
# Again, you can leave the preference group out completely, and just
# specify the keyword "notify_email" followed by a list of email
# addresses.
#
# The "karma" line in this file follows a special convention.
# It looks like this:
#
# karma:PREFNAME:name:user:pass:X
#
# where "name" is listed as a service in the tnsnames.ora file.
# "user" is the user to login to the database as, and "pass"
# is the password to use.  X is how often the karma.pl script
# should wake up to check your database.  You should have
# *many* of these lines, one for each database you wish to
# monitor.  Conversely you can specify:
#
# karma:ALL:user:pass:X
#
# meaning every entry in the tnsnames.ora file.  I'm not sure
# if this will be much use though, as they'll all have to have
# the same username and password.  If you have a service named 
# "ALL", sorry.  :-)
#
# In addition to the "karma" line, the "refresh" directive is
# special as well.  It looks like this:
#
# refresh:X
#
# X is how often the generated html page should refresh.
# It's probably a good idea for this value to be less than
# the refresh karma does for that database.
#
# PREFERENCE GROUPS
#
# These allow you to have different sets of preferences and apply
# them to different databases, or groups of databases.
#
# Specify a preference group in various lines like this:
#
# karma:PREFNAME:name:user:pass:X
# PREFNAME:notify_email:full:full:shull,root
# notify_alert:10:fragmentation,a,b,c
# *:notify_warning:15:hitratios,a,b,c
# *:rollback:1:99:97
# default:rollback:1:99:97
#
# Notice that anywhere you can specify a preference name you can
# leave blank, or use a "*", or specify default.  In fact if you
# don't wish to use preference groups, you do not have to specify
# them anywhere but in the karma line, which you would need only
# leave that field blank, or use a "*".
#
#---------------------------------------------------------------



#
# specifies databases to monitor
# 
# First field is always "karma" meaning, this is a database definition
# line.  The second field is a name from your tnsnames.ora file.  The
# The second field is a name from your tnsnames.ora file.  The
# third and fourth fields are your username and password respectively.
# Also, you'll notice that the first line specified below is not the 
# sys user.  If you specify another user besides sys or system, the user
# must have "SELECT ANY TABLE" privilege.



#
# NOTE:  We'll need a more secure way of specifying usernames and
# passwords for the future. 
#
karma:Tokyo:UNA:karma:amrak
karma:New York:AEON:karma:amrak
karma:New York:BAMBARA:karma:amrak

#
# refresh 
#
# first number is in minutes, how often karma refreshes
# (There should probably be some checking on this so if you 
# have a quicker refresh for some other service, karma will
# wake up to refresh those...)
#
refresh:5:75

#
# monitor redolog switching, threshold values in minutes
#
redolog:1:30:15

#
# rollback segment contention
#
rollback:1:0:0

#
# tablespace quotas
#
tablespace:1:85:95

#
# slow running sql, that is queries that perform a lot of disk reads
# the thresholds here amount to number of diskreads.  The query checks
# for anything in v$sqlarea above the specified threshold of diskreads
# (it does not consider executions assuming that (a) slow queries often
# don't get reexecuted over and over - debatable, and (b) it speeds up
# this query noticeably
#
slowsql:5:100:200

#
# ORA errors in the alert log
# These numbers represent the number of minutes
# we're concerned about.  Alert if we've had ORA- errors in
# the alert log in the last 60 minutes, warn if we've had
# any within 24 hours
#
alertlog:1:60:86400

#
# various system hit ratios
# (expressed as percentages...)
# below the given value is a warn or alert
#
#hitratios:1:95:70

#
# tablespace fragmentation
#
fragmentation:1:0:0

#
# objects nearing their maxextents or those which will not be able
# to allocate their next extent
#
# below we warn when we're at our second to last extent (1 from maxextents)
# and alert when we're AT our maxextents (0 from maxextents)
#
extents:1:2:1

#
# latch contention
#
latch:1:0:0

#
# monitors shared server and dispatcher process contention
# more than the give value % busy is a warn or alert
#
mts:1:50:75

#
# monitors OS statistics (if the table exists)
# 
# The code in karma will check for the existance of the KARMA_OS_STATS
# table and display NO_STATUS if it doesn't exist, however, it's
# cleaner to just comment out the service here if you haven't created
# the appropriate tables.
#
os:1:5:10

#
#
#
repqueue

#
#
#
reperror


#
# who to email
# one line for each address, or comma separated list
#
sean_new:notify_email:full:shull,root
*:notify_email:full:shull,roby,oracle

# 
# how often to email out each type (warning, alert), size of message
# to send (short for text pagers), and then a list of services that
# we want notification on.  If it's not in the list, warning/alert
# status will not trigger an email notification
#
notify_alert:10:fragmentation,a,b,c
notify_warning:15:hitratios,a,b,c

#
# similar to the above, except each preceded by a preference group
#
sean_new:notify_alert:5:up,hitratios
sean_new:notify_warning:30:hitratios,a,b,c

sean_new:refresh:5:75
sean_new:redolog:1:30:15
sean_new:rollback:1:0:0
sean_new:tablespace:1:85:95
sean_new:slowsql:1:100:200
sean_new:alertlog:1:60:86400
#sean_new:hitratios:1:95:70
sean_new:fragmentation:1:0:0
sean_new:extents:1:2:1
sean_new:latch:1:0:0
sean_new:mts:1:50:75
sean_new:os:1:5:10


Tokyo:refresh:5:75
Tokyo:redolog:1:30:15
Tokyo:rollback:1:0:0
Tokyo:tablespace:1:85:95
Tokyo:slowsql:1:100:200
Tokyo:alertlog:1:60:86400
Tokyo:hitratios:1:95:70
Tokyo:fragmentation:1:0:0
Tokyo:extents:1:2:1
Tokyo:latch:1:0:0
#Tokyo:mts:1:50:75
Tokyo:os:1:5:10

New York:refresh:5:75
New York:redolog:1:30:15
New York:rollback:1:0:0
New York:tablespace:1:85:95
New York:slowsql:1:100:200
New York:alertlog:1:60:86400
New York:hitratios:1:95:70
New York:fragmentation:1:0:0
New York:extents:1:2:1
New York:latch:1:0:0
New York:mts:1:50:75
New York:os:1:5:10
#
# look and feel config...
#
# whether or not to use blinking ICONS...
#
# If you want blinking for either warning or alerts
# you can specify ( true || yes || 1 ) and if you
# don't you can specify ( false || no || 0 )
#
warn_blink:true
alert_blink:true
pref_group_sections:true
