bionic (5) analysis.cfg.5.gz

Provided by: xymon_4.3.28-3build1_amd64 bug

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
       basis 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 comments and ignored.

CPU STATUS COLUMN SETTINGS

       LOAD warnlevel paniclevel

       If the system load exceeds "warnlevel"  or  "paniclevel",  the  "cpu"  status  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 minutes, 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 differs 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 offset 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 letter "U", e.g. "1024U".

       The special keyword "IGNORE" causes this filesystem to be ignored completely, 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
       devices, 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 interpreted 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: warnlevel=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 maximum 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 expression, 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 expression.  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)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 defines 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"  status  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] [OPTIONAL]

       The Xymon client extracts interesting lines from one or more logfiles - see the client-local.cfg(5)  man-
       page for information about how to configure 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  "WARNING"  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 temporary 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 exist.

       ifexist
              only checks the file if it exists. If the file is  reported  as  missing  by  the  client,  it  is
              ignored.

       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  digest 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  setting  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 normally 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 defined 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 sockets 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
       understand.  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|disabled|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.  "explanation"
       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
       going 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
       status 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 PATTERN 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 keywords (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 Xymon. "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 "Webservers" 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 hierarchy.

       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
       expression.  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  specified,  the
       host by default goes into a class named by the operating system.

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

       DISPLAYGROUP=groupstring  Rule  matching  an  alert  by the text of the display-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.
       DISPLAYGROUP=%database.  If there is no group-setting for the host, use "DISPLAYGROUP=NONE".

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

       TIME=timespecification  Rule  matching  by  the  time-of-day.  This  is  specified  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  admins  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 between 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 analysis.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
       significant. 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)