Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
ANALYSIS.CFG(5)		      File Formats Manual	       ANALYSIS.CFG(5)

NAME
       analysis.cfg - Configuration file for the xymond_client module

SYNOPSIS
       ~Xymon/server/etc/analysis.cfg

DESCRIPTION
       The  analysis.cfg  file	controls what color is assigned	to the status-
       messages	that are generated from	the Xymon client data -	typically  the
       cpu, disk, memory, procs- and msgs-columns. Color is decided on the ba-
       sis  of	some settings defined in this file; settings apply to specific
       hosts through a set of rules.

       Note: This file is only used on the Xymon server	- it is	 not  used  by
       the  Xymon  client, so there is no need to distribute it	to your	client
       systems.

FILE FORMAT
       Blank lines and lines starting with a hash mark (#) are treated as com-
       ments and ignored.

CPU STATUS COLUMN SETTINGS
       LOAD warnlevel paniclevel

       If the system load exceeds "warnlevel" or "paniclevel", the "cpu"  sta-
       tus will	go yellow or red, respectively.	These are decimal numbers.

       Defaults: warnlevel=5.0,	paniclevel=10.0

       UP bootlimit toolonglimit [color]

       The  cpu	status goes yellow/red if the system has been up for less than
       "bootlimit" time, or longer than	"toolonglimit".	The time  is  in  min-
       utes,  or  you  can  add	 h/d/w for hours/days/weeks - eg. "2h" for two
       hours, or "4w" for 4 weeks.

       Defaults: bootlimit=1h, toolonglimit=-1 (infinite), color=yellow.

       CLOCK max.offset	[color]

       The cpu status goes yellow/red if the system clock on the  client  dif-
       fers more than "max.offset" seconds from	that of	the Xymon server. Note
       that  this is not a particularly	accurate test, since it	is affected by
       network delays between the client and the server, and the load on  both
       systems.	 You  should therefore not rely	on this	being accurate to more
       than +/-	5 seconds, but it will let you catch a client clock that  goes
       completely wrong. The default is	NOT to check the system	clock.
       NOTE: Correct operation of this test obviously requires that the	system
       clock  of  the  Xymon server is correct.	You should therefore make sure
       that the	Xymon server is	synchronized to	the real clock,	e.g. by	 using
       NTP.

       Example:	Go yellow if the load average exceeds 5, and red if it exceeds
       10.  Also,  go  yellow for 10 minutes after a reboot, and after 4 weeks
       uptime. Finally,	check that the system clock is at most 15 seconds off-
       set from	the clock of the Xymon system and go red if that is exceeded.

	      LOAD 5 10
	      UP 10m 4w	yellow
	      CLOCK 15 red

DISK STATUS COLUMN SETTINGS
       DISK filesystem warnlevel paniclevel
       DISK filesystem IGNORE
       INODE filesystem	warnlevel paniclevel
       INODE filesystem	IGNORE

       If the utilization of "filesystem" is reported to exceed	"warnlevel" or
       "paniclevel", the "disk"	status will go yellow  or  red,	 respectively.
       "warnlevel"  and	 "paniclevel"  are  either the percentage used,	or the
       space available as reported by the local	"df" command on	the host.  For
       the latter type of check, the "warnlevel" must be followed by the  let-
       ter "U",	e.g. "1024U".

       The  special keyword "IGNORE" causes this filesystem to be ignored com-
       pletely,	i.e. it	will not appear	in the "disk"  status  column  and  it
       will  not  be tracked in	a graph. This is useful	for e.g. removable de-
       vices, backup-disks and similar hardware.

       "filesystem" is the mount-point where the filesystem is	mounted,  e.g.
       "/usr"  or  "/home".  A	filesystem-name	that begins with "%" is	inter-
       preted as a Perl-compatible  regular  expression;  e.g.	"%^/oracle.*/"
       will match any filesystem whose mountpoint begins with "/oracle".

       "INODE" works identical to "DISK", but uses the count of	i-nodes	in the
       filesystem instead of the amount	of disk	space.

       Defaults	 DISK:	warnlevel=90%,	paniclevel=95%	Defaults  INODE: warn-
       level=70%, paniclevel=90%

MEMORY STATUS COLUMN SETTINGS
       MEMPHYS warnlevel paniclevel
       MEMACT warnlevel	paniclevel
       MEMSWAP warnlevel paniclevel

       If the memory utilization exceeds the "warnlevel" or "paniclevel",  the
       "memory"	 status	will change to yellow or red, respectively.  Note: The
       words "PHYS", "ACT" and "SWAP" are also recognized.

       Example:	Go yellow if more than 20% swap	is used, and red if more  than
       40%  swap  is  used or the actual memory	utilisation exceeds 90%. Don't
       alert on	physical memory	usage.

	      MEMSWAP 20 40
	      MEMACT 90	90
	      MEMPHYS 101 101

       Defaults:

	      MEMPHYS warnlevel=100 paniclevel=101 (i.e. it will never go red).
	      MEMSWAP warnlevel=50 paniclevel=80
	      MEMACT  warnlevel=90 paniclevel=97

PROCS STATUS COLUMN SETTINGS
       PROC processname	minimumcount maximumcount color	[TRACK=id] [TEXT=text]

       The "ps"	listing	sent by	the  client  will  be  scanned	for  how  many
       processes  containing  "processname"  are  running,  and	 this  is then
       matched against the min/max settings defined here. If the running count
       is outside the thresholds, the color of the "procs" status  changes  to
       "color".

       To  check for a process that must NOT be	running: Set minimum and maxi-
       mum to 0.

       "processname" can be a simple string, in	which case  this  string  must
       show  up	 in the	"ps" listing as	a command. The scanner will find a ps-
       listing of e.g. "/usr/sbin/cron"	if you only specify  "processname"  as
       "cron".	 "processname"	can also be a Perl-compatiable regular expres-
       sion, e.g.  "%java.*inst[0123]" can be used to find entries in the  ps-
       listing	for  "java  -Xmx512m  inst2" and "java -Xmx256 inst3". In that
       case, "processname" must	begin with "%" followed	by the regular expres-
       sion.  Note that	Xymon defaults to case-insensitive  pattern  matching;
       if that is not what you want, put "(?-i)" between the "%" and the regu-
       lar expression to turn this off.	E.g. "%(?-i)HTTPD" will	match the word
       HTTPD only when it is upper-case.
       If  "processname" contains whitespace (blanks or	TAB), you must enclose
       the full	string in double quotes	- including the	"%" if you use regular
       expression matching. E.g.

	   PROC	"%xymond_channel --channel=data.*xymond_rrd" 1 1 yellow

       or

	   PROC	"java -DCLASSPATH=/opt/java/lib" 2 5

       You can have multiple "PROC" entries for	the  same  host,  all  of  the
       checks are merged into the "procs" status and the most severe check de-
       fines the color of the status.

       The  optional  TRACK=id	setting	 causes	 Xymon	to track the number of
       processes found in an RRD file, and put this  into  a  graph  which  is
       shown  on  the  "procs" status display. The id setting is a simple text
       string which will be used as the	legend for the graph, and also as part
       of the RRD filename. It is recommended that you use  only  letters  and
       digits for the ID.
       Note  that the process counts which are tracked are only	performed once
       when the	client does a poll cycle - i.e.	the counts represent snapshots
       of the system state, not	an average value over the client  poll	cycle.
       Therefore there may be peaks or dips in the actual process counts which
       will  not  show	up  in the graphs, because they	happen while the Xymon
       client is not doing any polling.

       The optional TEXT=text setting is used in the summary  of  the  "procs"
       status.	Normally,  the summary will show the "processname" to identify
       the process and the related count and limits. But this may be a regular
       expression which	is not easily recognizable, so if  defined,  the  text
       setting string will be used instead. This only affects the "procs" sta-
       tus  display  -	it  has	no effect on how the rule counts or recognizes
       processes in the	"ps" output.

       Example:	Check that "cron" is running:
	    PROC cron

       Example:	Check that at least 5 "httpd" processes	are running,  but  not
       more than 20:
	    PROC httpd 5 20

       Defaults:
	    mincount=1,	maxcount=-1 (unlimited), color="red".
	    Note that no processes are checked by default.

MSGS STATUS COLUMN SETTINGS
       LOG  logfilename	 pattern  [COLOR=color]	 [IGNORE=excludepattern]  [OP-
       TIONAL]

       The Xymon client	extracts interesting lines from	one or more logfiles -
       see the client-local.cfg(5) man-page for	information about how to  con-
       figure which logs a client should look at.

       The  LOG	 setting  determine  how  these	 extracts  of  log entries are
       processed, and what warnings or alerts trigger as a result.

       "logfilename" is	the name of the	logfile.  Only	logentries  from  this
       filename	 will  be  matched against this	rule.  Note that "logfilename"
       can be a	regular	expression (if prefixed	with a '%' character).

       "pattern" is a string  or  regular  expression.	If  the	 logfile  data
       matches	"pattern",  it will trigger the	"msgs" column to change	color.
       If no "color" parameter is present, the default is to go	"red" when the
       pattern is matched. To match against a  regular	expression,  "pattern"
       must begin with a '%' sign - e.g	"%WARNING|NOTICE" will match any lines
       containing  either  of  these  two  words.  Note	that Xymon defaults to
       case-insensitive	pattern	matching; if that is not what  you  want,  put
       "(?-i)"	between	 the  "%" and the regular expression to	turn this off.
       E.g. "%(?-i)WARNING" will match the word	WARNING	only when it is	upper-
       case.

       "excludepattern"	is a string or regular expression that can be used  to
       filter out any unwanted strings that happen to match "pattern".

       The OPTIONAL keyword causes the check to	be skipped if the logfile does
       not exist.

       Example:	 Trigger  a  red  alert	when the string	"ERROR"	appears	in the
       "/var/adm/syslog" file:
	    LOG	/var/adm/syslog	ERROR

       Example:	Trigger	a yellow warning on all	occurrences of the word	"WARN-
       ING" or "NOTICE"	in the "daemon.log" file, except those from the	 "lpr"
       system:
	    LOG	/var/log/daemon.log %WARNING|NOTICE COLOR=yellow IGNORE=lpr

       Defaults:
	    color="red", no "excludepattern".

       Note  that no logfiles are checked by default. Any log data reported by
       a client	will just show up on the "msgs"	column with status OK (green).

FILES STATUS COLUMN SETTINGS
       FILE filename [color] [things to	check] [OPTIONAL] [TRACK]

       DIR directoryname [color] [size<MAXSIZE]	[size>MINSIZE] [TRACK]

       These entries control the status	of the "files" column. They allow  you
       to check	on various data	for files and directories.

       filename	 and  directoryname  are names of files	or directories,	with a
       full path. You can use a	regular	expression to match the	names of files
       and directories reported	by the client, if you  prefix  the  expression
       with a '%' character.

       color is	the color that triggers	when one or more of the	checks fail.

       The  OPTIONAL  keyword causes this check	to be skipped if the file does
       not exist. E.g. you can use this	to check if files that should be  tem-
       porary  are  not	 deleted, by checking that they	are not	older than the
       max time	you would expect them to stick around, and then	using OPTIONAL
       to ignore the state where no files exist.

       The TRACK keyword causes	the size  of  the  file	 or  directory	to  be
       tracked	in an RRD file,	and presented in a graph on the	"files"	status
       display.

       For files, you can check	one or more of the following:

       noexist
	      triggers a warning if the	file exists. By	default, a warning  is
	      triggered	for files that have a FILE entry, but which do not ex-
	      ist.

       type=TYPE
	      where  TYPE is one of "file", "dir", "char", "block", "fifo", or
	      "socket".	Triggers warning if the	file is	not of	the  specified
	      type.

       ownerid=OWNER
	      triggers	a  warning  if the owner does not match	what is	listed
	      here.  OWNER is specified	either with the	numeric	 uid,  or  the
	      user name.

       groupid=GROUP
	      triggers	a  warning  if the group does not match	what is	listed
	      here.  GROUP is specified	either with the	numeric	 gid,  or  the
	      group name.

       mode=MODE
	      triggers	a  warning  if the file	permissions are	not as listed.
	      MODE is written in the standard octal notation, e.g.  "644"  for
	      the rw-r--r-- permissions.

       size<MAX.SIZE and size>MIN.SIZE
	      triggers	a warning it the file size is greater than MAX.SIZE or
	      less than	MIN.SIZE, respectively.	For filesizes, you can use the
	      letters "K", "M",	"G" or "T" to indicate that the	filesize is in
	      Kilobytes, Megabytes, Gigabytes or Terabytes,  respectively.  If
	      there is no such modifier, Kilobytes is assumed. E.g. to warn if
	      a	file grows larger than 1MB, use	size<1024M.

       mtime>MIN.MTIME mtime<MAX.MTIME
	      checks  how  long	 ago  the file was last	modified (in seconds).
	      E.g.  to check if	a file was updated within the past 10  minutes
	      (600  seconds):  mtime<600. Or to	check that a file has NOT been
	      updated in the past 24 hours: mtime>86400.

       mtime=TIMESTAMP
	      checks if	a file was last	modified at TIMESTAMP.	TIMESTAMP is a
	      unix epoch time (seconds since midnight Jan 1 1970 UTC).

       ctime>MIN.CTIME,	ctime<MAX.CTIME, ctime=TIMESTAMP
	      acts as the mtime	checks,	but for	the ctime timestamp (when  the
	      directory	 entry	of  the	 file  was last	changed, eg. by	chown,
	      chgrp or chmod).

       md5=MD5SUM, sha1=SHA1SUM, rmd160=RMD160SUM
	      and so on	for RMD160, SHA256, SHA512, SHA224, and	SHA384 trigger
	      a	warning	if the file checksum using the specified  message  di-
	      gest algorithm does not match the	one configured here. Note: The
	      "file"  entry in the client-local.cfg(5) file must specify which
	      algorithm	to use as that is the only one that will be sent.

       For directories,	you can	check one or more of the following:

       size<MAX.SIZE and size>MIN.SIZE
	      triggers a  warning  it  the  directory  size  is	 greater  than
	      MAX.SIZE	or  less  than MIN.SIZE, respectively. Directory sizes
	      are reported in whatever unit the	du command on the client  uses
	      -	 often	KB  or	diskblocks  - so MAX.SIZE and MIN.SIZE must be
	      given in the same	unit.

       Experience shows	that it	can be difficult to  get  these	 rules	right.
       Especially  when	 defining  minimum/maximum values for file sizes, when
       they were last modified etc. The	one thing you must remember when  set-
       ting  up	 these checks is that the rules	describe criteria that must be
       met - only when they are	met will the status be green.

       So "mtime<600" means "the difference between current time and the mtime
       of the file must	be less	than 600 seconds - if  not,  the  file	status
       will go red".

PORTS STATUS COLUMN SETTINGS
       PORT  criteria  [MIN=mincount]  [MAX=maxcount] [COLOR=color] [TRACK=id]
       [TEXT=displaytext]

       The "netstat" listing sent by the client	will be	scanned	for  how  many
       sockets match the criteria listed.  The criteria	you can	use are:

       LOCAL=addr
	      "addr"  is a (partial) local address specification in the	format
	      used on the output from netstat.

       EXLOCAL=addr
	      Exclude certain local addresses from the rule.

       REMOTE=addr
	      "addr" is	a (partial) remote address specification in the	format
	      used on the output from netstat.

       EXREMOTE=addr
	      Exclude certain remote addresses from the	rule.

       STATE=state
	      Causes only the sockets in the specified state to	 be  included,
	      "state"  is  usually LISTEN or ESTABLISHED but can be any	socket
	      state reported by	the clients "netstat" command.

       EXSTATE=state
	      Exclude certain states from the rule.

       "addr" is typically "10.0.0.1:80" for the IP  10.0.0.1,	port  80.   Or
       "*:80" for any local address, port 80. Note that	the Xymon clients nor-
       mally  report  only the numeric data for	IP-addresses and port-numbers,
       so you must specify the port number (e.g. "80") instead of the  service
       name ("www").
       "addr"  and  "state" can	also be	a Perl-compatiable regular expression,
       e.g.  "LOCAL=%[.:](80|443)" can be used to find entries in the  netstat
       local  port for both http (port 80) and https (port 443). In that case,
       portname	or state must begin with "%" followed by the reg.expression.

       The socket count	found is then matched against the min/max settings de-
       fined here. If the count	is outside the thresholds, the	color  of  the
       "ports" status changes to "color".  To check for	a socket that must NOT
       exist: Set minimum and maximum to 0.

       The optional TRACK=id setting causes Xymon to track the number of sock-
       ets  found  in an RRD file, and put this	into a graph which is shown on
       the "ports" status display. The id setting  is  a  simple  text	string
       which will be used as the legend	for the	graph, and also	as part	of the
       RRD  filename.  It  is recommended that you use only letters and	digits
       for the ID.
       Note that the sockets counts which are tracked are only performed  once
       when the	client does a poll cycle - i.e.	the counts represent snapshots
       of  the	system state, not an average value over	the client poll	cycle.
       Therefore there may be peaks or dips in the actual sockets counts which
       will not	show up	in the graphs, because they  happen  while  the	 Xymon
       client is not doing any polling.

       The TEXT=displaytext option affects how the port	appears	on the "ports"
       status page. By default,	the port is listed with	the local/remote/state
       rules  as  identification, but this may be somewhat difficult to	under-
       stand. You can then use e.g. "TEXT=Secure Shell"	to  make  these	 ports
       appear with the name "Secure Shell" instead.

       Defaults:  mincount=1,  maxcount=-1 (unlimited),	color="red".  Note: No
       ports are checked by default.

       Example:	Check that the SSH daemon is listening on port 22.  Track  the
       number of active	SSH connections, and warn if there are more than 5.
	       PORT LOCAL=%[.:]22$ STATE=LISTEN	"TEXT=SSH listener"
	       PORT LOCAL=%[.:]22$ STATE=ESTABLISHED MAX=5 TRACK=ssh TEXT=SSH

SVCS status (Microsoft Windows clients)
       SVC    servicename   status=(started|stopped)   [startup=automatic|dis-
       abled|manual]

DS - RRD based status override
       DS column filename:dataset rules	COLOR=colorname	TEXT=explanation

       "column"	is the statuscolumn that will be modified. "filename"  is  the
       name  of	 the  RRD  file	 holding  the  data  you  use  for comparison.
       "dataset" is the	name of	the dataset in the RRD	file  -	 the  "rrdtool
       info" command is	useful when determining	these.	"rules"	determine when
       to  apply  the  override. You can use ">", ">=",	"<" or "<=" to compare
       the current measurement value against one or more thresholds. "explana-
       tion" is	a text that will be shown to explain the override  -  you  can
       use  some  placeholders	in the text: "&N" is replaced with the name of
       the dataset, "&V" is replaced with the current value, "&L" is  replaced
       by the low threshold, "&U" is replaced with the upper threshold.

       NOTE:  This  rule  uses the raw data value from a client	to examine the
       rules. So this type of test is only really suitable for	datasets  that
       are  of	the  "GAUGE" type. It cannot be	used meaningfully for datasets
       that use	"COUNTER" or "DERIVE" -	e.g. the datasets  that	 are  used  to
       capture network packet traffic -	because	the data stored	in the RRD for
       COUNTER-based  datasets undergo a transformation	(calculation) when go-
       ing into	the RRD. Xymon does not	have direct access to  the  calculated
       data.

       Example:	Flag "conn" status a yellow if responsetime exceeds 100	msec.
	    DS	conn tcp.conn.rrd:sec >0.1 COLOR=yellow	TEXT="Response time &V
       exceeds &U seconds"

MQ Series SETTINGS
       MQ_QUEUE	queuename [age-warning=N]  [age-critical=N]  [depth-warning=N]
       [depth-critical=N]
       MQ_CHANNEL channelname [warning=PATTERN]	[alert=PATTERN]

       This  is	 a  set	 of  checks for	checking the health of IBM MQ message-
       queues.	It requires the	"mq.sh"	or similar collector module to run  on
       a  node with access to the MQ "Queue Manager" so	it can report the sta-
       tus of queues and channels.

       The MQ_QUEUE setting checks the health of a single queue: You can  warn
       (yellow)	or alert (red) based on	the depth of the queue,	and/or the age
       of  the oldest entry in the queue. These	values are taken directly from
       the output generated by the "runmqsc" utility.

       The MQ_CHANNEL setting checks the health	of a single  MQ	 channel:  You
       can warn	or alert based on the reported status of the channel. The PAT-
       TERN  is	 a normal pattern, i.e.	either a list of status	keywords, or a
       regular expression pattern.

CHANGING THE DEFAULT SETTINGS
       If you would like to use	different defaults for the settings  described
       above,  then you	can define the new defaults after a DEFAULT line. E.g.
       this would explicitly define all	of the default settings:

	      DEFAULT
		   UP	   1h
		   LOAD	   5.0 10.0
		   DISK	   * 90	95
		   MEMPHYS 100 101
		   MEMSWAP 50 80
		   MEMACT  90 97

RULES TO SELECT	HOSTS
       All of the settings can be applied to a group of	 hosts,	 by  preceding
       them with rules.	A rule defines of one of more filters using these key-
       words  (note that this is identical to the rule definitions used	in the
       alerts.cfg(5) file).

       PAGE=targetstring Rule matching an alert	by the name of the page	in Xy-
       mon. "targetstring" is the path of the page as defined in the hosts.cfg
       file. E.g. if you have this setup:

	      page servers All Servers
	      subpage web Webservers
	      10.0.0.1 www1.foo.com
	      subpage db Database servers
	      10.0.0.2 db1.foo.com

       Then the	"All servers" page  is	found  with  PAGE=servers,  the	 "Web-
       servers"	 page  is  PAGE=servers/web and	the "Database servers" page is
       PAGE=servers/db.	Note that you can  also	 use  regular  expressions  to
       specify	the  page  name,  e.g.	PAGE=%.*/db  would  find the "Database
       servers"	page regardless	of where this page was placed in  the  hierar-
       chy.

       The  top-level page has a the fixed name	/, e.g.	PAGE=/ would match all
       hosts on	the Xymon frontpage. If	you need it in a  regular  expression,
       use  PAGE=%^/  to  avoid	matching the forward-slash present in subpage-
       names.

       EXPAGE=targetstring Rule	excluding a host if the	pagename matches.

       HOST=targetstring Rule matching a host by the hostname.	"targetstring"
       is either a comma-separated  list  of  hostnames	 (from	the  hosts.cfg
       file),  "*"  to	indicate "all hosts", or a Perl-compatible regular ex-
       pression.  E.g. "HOST=dns.foo.com,www.foo.com" identifies two  specific
       hosts;  "HOST=%www.*.foo.com EXHOST=www-test.foo.com" matches all hosts
       with a name beginning with "www", except	the "www-test" host.

       EXHOST=targetstring Rule	excluding a host by matching the hostname.

       CLASS=classname Rule match by the client	class-name.  You  specify  the
       class-name   for	  a   host   when  starting  the  client  through  the
       "--class=NAME" option to	the runclient.sh script. If no class is	speci-
       fied, the host by default goes into a class named by the	operating sys-
       tem.

       EXCLASS=classname Exclude all hosts belonging to	"classname" from  this
       rule.

       DISPLAYGROUP=groupstring	Rule matching an alert by the text of the dis-
       play-group (text	following the group, group-only, group-except heading)
       in  the	hosts.cfg  file.  "groupstring"	 is  the  text	for the	group,
       stripped	of any HTML tags. E.g. if you have this	setup:

	      group Web
	      10.0.0.1 www1.foo.com
	      10.0.0.2 www2.foo.com
	      group Production databases
	      10.0.1.1 db1.foo.com

       Then the	hosts in the Web-group can be matched  with  DISPLAYGROUP=Web,
       and  the	 database servers can be matched with DISPLAYGROUP="Production
       databases".  Note that you can also use regular expressions, e.g.  DIS-
       PLAYGROUP=%database.   If  there	 is no group-setting for the host, use
       "DISPLAYGROUP=NONE".

       EXDISPLAYGROUP=groupstring Rule excluding a group by matching the  dis-
       play-group string.

       TIME=timespecification Rule matching by the time-of-day.	This is	speci-
       fied  as	 the  DOWNTIME time specification in the hosts.cfg file.  E.g.
       "TIME=W:0800:2200" applied to a rule will make this rule	active only on
       week-days between 8AM and 10PM.

       EXTIME=timespecification	Rule excluding by  the	time-of-day.  This  is
       also  specified	as  the	 DOWNTIME  time	specification in the hosts.cfg
       file.  E.g. "TIME=W:0400:0600" applied to a rule	will  make  this  rule
       exclude	on  week-days  between 4AM and 6AM. This applies on top	of any
       TIME= specification, so both must match.

DIRECTING ALERTS TO GROUPS
       For some	tests -	e.g. "procs" or	"msgs" - the right group of people  to
       alert  in case of a failure may be different, depending on which	of the
       client rules actually detected a	problem. E.g. if you have PROCS	 rules
       for a host checking both	"httpd"	and "sshd" processes, then the Web ad-
       mins  should handle httpd-failures, whereas "sshd" failures are handled
       by the Unix admins.

       To handle this, all rules can have a "GROUP=groupname" setting.	When a
       rule with this setting triggers a yellow	or red status,	the  groupname
       is passed on to the Xymon alerts	module,	so you can use it in the alert
       rule definitions	in alerts.cfg(5) to direct alerts to the correct group
       of people.

RULES: APPLYING	SETTINGS TO SELECTED HOSTS
       Rules must be placed after the settings,	e.g.

	      LOAD 8.0 12.0  HOST=db.foo.com TIME=*:0800:1600

       If you have multiple settings that you want to apply the	same rules to,
       you  can	 write the rules *only*	on one line, followed by the settings.
       E.g.

	      HOST=%db.*.foo.com TIME=W:0800:1600
		   LOAD	8.0 12.0
		   DISK	/db  98	100
		   PROC	mysqld 1

       will apply the three settings to	all of the "db"	hosts on week-days be-
       tween 8AM and 4PM. This can be  combined	 with  per-settings  rule,  in
       which case the per-settings rule	overrides the general rule; e.g.

	      HOST=%.*.foo.com
		   LOAD	7.0 12.0 HOST=bax.foo.com
		   LOAD	3.0 8.0

       will  result  in	 the  load-limits being	7.0/12.0 for the "bax.foo.com"
       host, and 3.0/8.0 for all other foo.com hosts.

       The entire file is evaluated from the top  to  bottom,  and  the	 first
       match found is used. So you should put the specific settings first, and
       the generic ones	last.

NOTES
       For the LOG, FILE and DIR checks, it is necessary also to configure the
       actual  file-  and  directory-names in the client-local.cfg(5) file. If
       the filenames are not listed there, the clients will  not  collect  any
       data  about  these  files/directories,  and  the	settings in the	analy-
       sis.cfg file will be silently ignored.

       The ability to compute file checksums with MD5, SHA1 or	RMD160	should
       not  be	used  for  general-purpose  file integrity checking, since the
       overhead	of calculating these on	a large	number of files	can be signif-
       icant. If you need this,	look at	tools designed for this	purpose	- e.g.
       Tripwire	or AIDE.

       At the time of writing (april 2006), the	SHA-1  and  RMD160  algorithms
       are considered cryptographically	safe. The MD5 algorithm	has been shown
       to  have	 some  weaknesses,  and	is not considered strong enough	when a
       high level of security is required.

SEE ALSO
       xymond_client(8), client-local.cfg(5), xymond(8), xymon(7)

Xymon			  Version 4.3.30:  4 Sep 2019	       ANALYSIS.CFG(5)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=analysis.cfg&sektion=5&manpath=FreeBSD+Ports+14.3.quarterly>

home | help