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 pro-
       cesses containing "processname" are running, and	this is	 then  matched
       against the min/max settings defined here. If the running count is out-
       side 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  pro-
       cesses  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  pro-
       cessed, 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.28: 17 Jan 2017	       ANALYSIS.CFG(5)

NAME | SYNOPSIS | DESCRIPTION | FILE FORMAT | CPU STATUS COLUMN SETTINGS | DISK STATUS COLUMN SETTINGS | MEMORY STATUS COLUMN SETTINGS | PROCS STATUS COLUMN SETTINGS | MSGS STATUS COLUMN SETTINGS | FILES STATUS COLUMN SETTINGS | PORTS STATUS COLUMN SETTINGS | SVCS status (Microsoft Windows clients) | DS - RRD based status override | MQ Series SETTINGS | CHANGING THE DEFAULT SETTINGS | RULES TO SELECT HOSTS | DIRECTING ALERTS TO GROUPS | RULES: APPLYING SETTINGS TO SELECTED HOSTS | NOTES | SEE ALSO

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

home | help