# @(#)parm           12.00.000                              =*=
#
# Edit this file as needed to correspond to your specific performance
# data collection needs.
#
#                    I M P O R T A N T   N O T E
#
# The parm file is now pre-processed with m4 and is identical on all
# Unix platforms. The "PARMOS" macro is pre-set to the output of 'uname'
# and that can be used to make additional per-platform changes. Customers
# wishing to have different application definitions on different systems
# also have this option. See below.
#
# This parm file is used by the HP Performance Agent and Glance products.
# Glance and perfd use the application definitions, the javaarg flag and
# all the other options that pertain to measurement.
#
# On AIX, <PERFDIR> is /usr/lpp/perf, on other Unix systems, /opt/perf.
#
# Changes to this configuration file will not take effect until the tools
# are restarted. See the HP Performance Agent documentation for specific
# information about managing oacore data collection. Printable manuals
# are available in the <PERFDIR>/paperdocs/ directory.
# Release notes are available in the <PERFDIR>/ReleaseNotes directory.

# The default for the following id parameter is to use the system's
# hostname. If you want to specify a different name for the metric
# GBL_SYSTEM_ID, other than the hostname, uncomment the following and
# replace "system-id" with a different name.

# id = system-id

#
# The following log parameter controls the type of data logged by
# the oacore process. Choosing to log or not log each class of
# data does not generally affect any of the other classes. For example, if
# you are not going to use filesystem (FS_* metrics) data, you could
# choose not to log filesystem class of data, thus saving overhead in the
# performance  data store. Use the utility program's scan function, after collection
# has been active for a few days, to see how the different classes of data
# are using space and adjust collection to best meet your needs.
#
# When running on a host (or an AIX LPAR), you can choose to enable guest
# performance data logging by adding the 'logical' keyword. See additional
# instructions for enabling the BYLS_ class of metrics in the Perf Agent
# installation guide found under <PERFDIR>/paperdocs/ovpa/C directory.

log global application process device=disk,cpu,filesystem transaction

# The following parameter controls how large the OA database files
# (in megabytes) will get before the older data will be rolled out. The
# logfiles are stored in /var/opt/OV/databases/oa

size global=30, application=20, process=30, device=20, transaction=10

# The following parameters control the size of Custom data logged using mechanisms like DSI.
# It will limit the maximum size of DB file(in megabytes) for custom class specified.
# Rules for Data Source and Class name are as follows.
# If size is not mentioned, default size of 1024 mb will be used.
# If size is lesser than 1 mb, it will default to 1 mb.
# Maximum size supported is 2146 mb.

# Syntax for customsize parameter will be like this:
# customsize "Datasourcename.Classname1"=10, "Datasourcename.Classname2"=10, "Datasourcename.*=2", "*.Classname2"=10, "*.*"=1
# for e.g.:
# customsize "Datasourcename.MYCLASS"=2, "NET-APP.*"=9, "*.*"=50
# It means that the maximum size of class MYCLASS in Datasourcename datasource is 2mb,
#  for all the classes under NET-APP datasource would be 9 mb, and for all others it is 50 mb
#   
# customsize  "Datasourcename.*"=2
# The maximum size of all classes under the datasource DDF would be 2mb
#
# customsize "*.*"=3
# The maximum size of all custom classes would be 3 mb
#
# customsize  "Datasourcename*.CL*"=2 is an invalid syntax.
#

# The following parameter specifies the collection intervals for process and
# other classes of data. The default collection intervals used by oacore are
# 60 seconds for process data, 300 seconds for global and all other classes.
# The following collectioninterval parameter allows you to modify these
# values subject to following constraints. The process collection interval
# can be in the range of 5 to 60 seconds, in steps of 5 seconds. It must also
# be a multiple of the subinterval at which process data is sampled (see
# below), and it must divide evenly into the global collection interval.
# The global collection interval must be 15, 30, 60, or 300 seconds. The
# global interval must be greater than or equal to process interval, and
# an even multiple of the process interval. For more information, refer
# to the section "Configure Data Logging Intervals" of chapter 2 of the
# HP Performance Agent User's Manual. The global interval applies to the global
# metrics and all non-process metric classes such as filesystem
# and application.

# collectioninterval process=60, global=300

ifelse(PARMOS,HP-UX,,
# This ifelse statement will be executed for all OS types, EXCEPT HPUX
#
# The subprocinterval setting can override the default subinterval that
# oacore uses to sample process instrumentation. By default, oacore
# probes OS instrumentation every few seconds in order to catch short-lived
# processes. This allows the process collection logging interval (above) to
# be set for longer periods but still capture fleeting process data. The
# default value for subprocinterval is 5 seconds. On systems with
# thousands of active processes, the subinterval should be made longer to
# reduce overall oacore overhead. On systems with many short-lived
# processes that you may wish to log, setting the subinterval lower could be
# considered, although the effect on oacore overhead should be monitored.
# The subprocinterval parameter can be set as low as 1 second and as high
# as 30 seconds, but it must be set to a value that is an even factor of the
# process collection interval. For example, if the global and process
# collection intervals are both set to 60, the following values are valid
# for subprocinterval: 1, 2, 3, 4, 5, 6, 10, 12, 15, 20, or 30. (The default
# value for suprocinterval is 5, if it is not specified or commented out)
#
# Note: The recommendation is to set subprocinterval to the same value as 
# process collection interval on highly loaded systems with a large number
# of started and active process. i.e. subprocinterval = 60

# subprocinterval = 10
)

ifelse(PARMOS,SunOS,
# The following zone_app flag, when set to true, will affect the
# collection of all application class metrics (APP_*). Application metrics
# will be collected based on zones running on the Perf Agent installed machine.
# All user-defined application sets listed in parm file will be ignored.
# Example :
# Consider a Solaris machine running with two non-global zones, viz. zone1 and
# zone2. PA/Glance will ignore parm file application sets and will create three
# applications, named 'global', 'zone1' and 'zone2'. Performance measurement
# for each application will be based on measurement values obtained from
# processes running under respective zones.
#
# NOTE: Zones are only supported on Solaris 10 and above versions.

# zone_app = true

# The following parameter will cause application grouping to be based on
# Solaris projects. It is only meaningful on Solaris systems. When project_app
# is set to true, each entry in the project file will be turned into an
# application entry, with the application ID set to the project ID.
# Note that if projects are created after the start of measurement, they
# will only result in new applications when they become active, i.e. when
# processes belonging to the new projects become active.

# project_app = true

# The following proclist flag, when set to all in global zone, will make
# all the processes i.e those running in global and non-global zones,visible.
# When this flag is set to local, only the global zone processes are visible.
# This flag is ignored in non-global zones.

# proclist = all

# The following appproc flag, when set to all, will affect the collection of
# APP_CPU*, APP_DISK*, APP_IO*, APP_MEM*, APP_MINOR*, APP_MAJOR*, APP_PRI*
# and APP_REV* metrics on global zone. These metrics will be calculated by
# considering the processes of the application that run in global zone and
# non-global zones. However when proclist is local, only the global zone
# processes are considered. When this flag is set to local, the APP metrics
# will be calculated by considering only the processes of the application
# that run in global zone. This flag is ignored in non-global zones.

# appproc = all
)

# The following parameter specifies the thresholds for different classes
# of metrics. When the threshold value specified is exceeded for a
# particular instance of a class of data, a record for that instance will be
# logged by oacore. You can specify lower values for the thresholds to
# enable oacore to log more data (because instances of the
# class of data will be more likely to be logged), or you can specify higher
# values for the thresholds to see fewer records logged on average.
#
# The procthreshold parameter specifies the thresholds for the process metric
# class. With the default values, processes that used more than 10% of a
# processor's worth of cpu during the last interval OR had a virtual memory
# set size over 900 Megabytes OR had an average physical disk I/O rate
# (block device I/O rate on AIX or Solaris) greater than 5 KB per second
# OR had an I/O rate of 100 Kilobytes per second will get logged
#
# Busy systems may log many interesting processes with the default options,
# and if you are not using the process data, you can reduce collection
# overhead by increasing the threshold values. The more process data that is
# logged, the quicker the process table will fill up and start rolling out
# old data.
#
# If you specify the "nonew, nokilled" settings, by default, New and Killed
# processes will not get logged thus saving space in process table. The New
# and Killed processes will be logged when these processes exceed any of
# the thresholds. If you want to log new and killed processes that did not
# exceed any of the thresholds, remove the "nonew, nokilled" settings.
# The procthreshold settings do not affect other classes of data 
# except for process table.
#
# NOTE: The procthreshold parameter is same as the threshold parameter
# available in earlier versions of the HP Performance Agent. Both the
# keywords are supported.

procthreshold cpu = 10, memory = 900, disk = 5, io = 100, nonew, nokilled

# The following parameter enables logging of process command line arguments
# in the Perf Agent databases. You can enable this by setting the value to 1.
# By default, the value for this parameter is set to 0 and the
# logging of process commands is disabled.

#proccmd = 1

# The appthreshold parameter specifies the thresholds for the application
# metric class. The value is compared against the applications' cpu
# utilization metric (APP_CPU_TOTAL_UTIL). For example, if the value is set
# to 10, applications that use more than 10% of cpu of the system overall
# during the last interval will be logged.
# If the value is not set, or left commented out as in the default parm
# file, then any application with cpu utilization greater than 0% will be
# logged each interval.

# appthreshold cpu = 10

# The diskthreshold parameter specifies the thresholds for disk metric class.
# The value is compared against the disk utilization metric BYDSK_UTIL metric.
# For example, if the value is set to 10, disks that are busy for more than 10%
# during the last interval will be logged. If the value is not specified
# or commented out, disks that are not idle will be logged.

# diskthreshold util = 10

# The bynetifthreshold parameter specifies the thresholds for netif metric
# class. The value is compared against number of successful physical packets
# sent or received per second, through a network interface, represented by
# BYNETIF_PACKET_RATE metric. For example, if the value is set to 60, network
# interfaces that transferred more than 60 packets per second in last interval
# will be logged. If the value is not specified or commented out, network
# interfaces that are not idle will be logged each interval.

# bynetifthreshold iorate = 60

# The fsthreshold parameter specifies the thresholds for filesystem metric
# class. The value is compared against the percentage of space used in a
# file system, represented by FS_SPACE_UTIL metric. For example, if the value
# is set to 70, file systems with more than 70% of disk space used during the
# last interval will be logged. If the value is not specified or commented
# out, all the filesystems will be logged.

# fsthreshold util = 70

# The fstypes parameter specifies the filesystem types for which data
# will be collected. The arguments are one or multiple comma-separated
# regular expressions. If this option is not present, the list will be
# that of the previous versions of PA/Glance. In this case:
# Please note the quotes for fstypes, otherwise m4 will treat it as quote
# for ifelse. If you are upgrading there is a possibility of you hitting
# this problem for multiple filesystems.
# 

ifelse(PARMOS,Linux,
# `fstypes = !nfs*,autofs,mvfs'
,PARMOS,HP-UX,
# `fstypes = `!tmpfs'
,PARMOS,SunOS,
# Note that not collecting ZFS data will affect cache and other metrics
# and is not recommended.
#
# `fstypes = ufs,zfs,vxfs,tmpfs'
,PARMOS,AIX,
# `fstypes = aix,jfs*'
)
#
# An empty list, as in:
#
# fstypes =
#
# produces the same result as:
#
# fstypes = *
#
# If the first character in the list is an exclamation point, the first item of list is
# an exclusion item. This is a change in upgrade which fixes this behaviour. 
# We recommend (not mandatory ) whenever possible please put it in the
# ifelse block rather than outside.
# For example:
#
# `fstypes = !nfs*,mvfs'
#
# means that data will be collected for non-NFS (any version) and MVFS
# filesystems.

# fstypes = *

# The bycputhreshold parameter specifies the thresholds for cpu metric class.
# The value is compared against the percentage of time the cpu was busy,
# represented by BYCPU_CPU_TOTAL_UTIL metric. For example, if the value is set
# to 90, cpus that are busy more than 90% during the last interval will be
# logged. If the value is not specified or commented out, cpus that are not
# idle will be logged.

# bycputhreshold cpu = 90

ifelse(PARMOS,HP-UX,
define(`haslvthreshold',`true')
,PARMOS,SunOS,
define(`haslvthreshold',`true')
)
ifelse(haslvthreshold,true,
# The lvthreshold parameter specifies the thresholds for logical volume
# metric class. This value is compared against number I/Os per second which
# is a sum of LV_READ_RATE and LV_WRITE_RATE. For example, if the value is
# set to 35, logical volumes that generated more than 35 I/Os per second
# in the last interval will be logged. If the value is not specified or
# commented out, logical volumes that generate I/Os will be logged.

#lvthreshold iorate = 35
)

# The following parameter specifies the interval, in seconds, at which
# oacore logs the application and device data classes even if
# the data does not meet the threshold conditions specified.
# Device data flushing can be disabled by setting a value 0.
# If the flush parameter is set to zero (i.e. flush = 0) the oacore never
# logs the application and device instances which are not meeting threshold.
# For example, if flush=3600, all instances of applications and device data
# will be logged once per hour, irrespective of the thresholds specified.

# flush = 600

# The following keyword controls the modification of application-class
# data to account for any difference between the global (system-wide) data
# and the sum of per-application data. Application data is derived from
# process-level instrumentation. Typically, there is a small difference
# between the global metrics and the sum of applications, but on systems
# with high process creation rates, this difference might be significant.
# Also note that lower values for the subprocinterval keyword (above)
# will reduce the difference between global metrics and the sum of
# applications on platforms other than HP-UX.
#
# The special gapapp application, if uncommented below, will be the
# name of the application which accounts for this difference.
# Following is behavior for different values of the gapapp keyword:
# Option 1: gapapp
# If gapapp is blank, an application named gapapp will be added to the
# application list.
# Option 2: gapapp = UnassignedProcesses
# An application by the name UnassignedProcesses will be added to
# the application list.
# Option 3: gapapp = ExistingApplicationName
#      (or) gapapp = other
# The difference to the global values will be added to the specified
# application instead of adding a new entry to the application list.
#
# gapapp = UnassignedProcesses

#
# The following cachemem option determines how cache memory is bucketed.
# The value can be 'user' (or just 'u') or 'free' (or just 'f').
ifelse(PARMOS,Linux,
# The default is 'free', to preserve compatibility with previous behavior.
# Until 2.6.18 kernels, the logical assignment of cache memory was free,
# as documented in many Linux blogs. Because at least some 2.6.18 kernels
# include shared memory segments as cache, it may make more sense not to
# count cache as free memory, particularly on Oracle servers, which allocate
# large shared memory segments.

# cachemem = free
,PARMOS,AIX,
cachemem = free
,
# On HP-UX, this option does not affect GBL_MEM_USER[_UTIL]

# cachemem = user
)

ifelse(PARMOS,AIX,
# The "ignore_mt" option, when set to true, will cause CPU related global
# metrics to report values which are normalized against the number of
# active cores on the system, as opposed to the number of active
# logical CPUs.
# This option is a no-op if hardware multi-threading is not enabled and
# the metric GBL_IGNORE_MT will report "na" on such hardware.

# ignore_mt = false
)

# The following javaarg flag, when set to true, will affect the
# PROC_PROC_ARGV1 metric value for java processes. Instead of using the
# literal value of the first process argument, the PROC_PROC_ARGV1 metric
# will be set to the java classname or jarfile name if it is found in the
# command string. This can be useful for application definitions using the
# new argv1= discriminator:

javaarg = true

# Following are examples of application definitions specific to java.
# To make application data useful on your system, you should customize
# your application definitions to match the processes running on your system:
#
# This example will only work if javaarg is true (see above). It will
# bucket java processes into the application myco-java when their classname
# begins with com.myco.
# application = myco-java
# file = java
# argv1 = com.myco.*
#
# This example will work irrespective of whether javaarg is set to true or
# not:
# application = newbie
# cmd = *java *[Hh]ello[Ww]orld*


# Listed below are sample application definitions. You should
# edit or replace them with entries that match the applications used on
# your system. You may remove any application definitions which are not
# useful to you. See the <PERFDIR>/examples/ovpaconfig/parm_apps file for
# additional application definitions.
#
# Customers wishing to add their own app definitions to the default ones
# in a separate file can uncomment the 'include' line after creating this
# file. Others who may wish to use their own app definitions exclusively,
# in a separate file, can do the same but also delete all the contents
# below that line. If additional include files may or may not be present,
# 'sinclude' should be used instead of 'include' to avoid warnings.

# include(/var/opt/perf/parm.apps)

# This application may be appropriate for networked environments:
application = network
file = nfs*,biod,automount,*inetd,snmp*,rpc*,llbd,netfmt,portmap
file = rbootd,telnet*,ftp*,*rlogin*,remsh*,rcp,nktl*,nvsisr,ttisr
file = lcsp,gcsp,strmen,strweld,vtdaemon,mib*,trapdest*,*web*,xntpd,yp*
ifelse(PARMOS,HP-UX,
`file = hp_unixagt,ntl*,pty*'
,PARMOS,Linux,
`file = amd'
)

# This application could be used on systems which experience memory bottlenecks
# The files used for memory management differ on different platforms.
application = memory_management
ifelse(PARMOS,Linux,
`file = kdmflush*,pdflush*,kswap*,mmem*'
,PARMOS,HP-UX,
`file = swapper,vhand,syncer,pageout,fsflush,vx*d,pagezerod'
,PARMOS,SunOS,
`file = swapper,vhand,syncer,pageout,fsflush'
,PARMOS,AIX,
`file = swapper,xmgc,lrud,psgc'
)

# This application is defined to know the operations agent processes
# resource utilization
application = OperationsAgent
file = ovcd, ovbbccb, ovconfd, ovbbcrcp, ovcodautil, extract, utility
file = opcgeni, ompolparm, opceca, opcecaas, agtrep, dsilog, perfalarm
file = opcmona, opcmsga, opcmsgi, opcacta, opcle, opcwbemi, opctrapi
file = oacore, midaemon, ttd, perfd, hpsensor, glance, xglance
file = AHSCollector, opcconfigfile, xglance-bin


# This application may be appropriate for X or Motif environments:
# application = xwindows
# file = X*,xload,xclock,*term,grmd,softmsg*,vue*
# file = gdm*,kdm*,kde*,gnome*

# Note: this generic root user entry should be specified at the end of your
# application definitions, if you choose to keep it, because it will
# pick up all processes owned by root which were not included in preceeding
# application definitions.
application = other_user_root
user = root