About filetest
|
basics
|
|
syntax
|
module filetest {
op (any | all)
[type <flags>]
[grep <relation>]
[showline <boolean>]
[timewarn <number>]
[timeprob <number>]
[timemax <number>]
[countwarn <relation>]
[countprob <relation>]
name <string>
[name ...]
[matchone (newest | oldest)]
}
via <transport>
|
Dependencies
Arguments
Name |
Type |
Value |
op |
string, one of 'any' or 'all' |
any indicates that any one of the three supported test
(type, grep, or time) succeeding will cause the module to succeed.
all indicates that all requested tests must be successful.
|
type |
optional flags, any of 'rwxfdcbpugksRWXFDCBPUGKS' |
Shell style tests to be performed.
- r: File is readable
- w: File is writeable
- x: File is executable
- f: File exists and is a plain file
- d: File is a directory
- c: File exists and is character special
- b: File exists and is block special
- p: File is a pipe
- u: File is setuid
- g: File is setgid
- k: File is sticky
- s: File is non-zero in size
All types specified must match in order for the test portion of
the module to succeed. The capital flags negate the meaning of
the corresponding test.
|
grep |
optional relation, reg/regv only |
A regular expression that must be found in the contents of the
file (or must not be found, for regv). If the file is empty and
regv was specified or if the file does not exist, the grep test will
still be considered successful.
|
showline |
optional boolean, default is 'no' |
When the grep test is specified with a regv
relation, report line numbers of matching expressions.
|
timewarn |
optional number between 1 and infinity |
If a matching file has existed for at least the specified number
of minutes, a warning is generated.
|
timeprob |
optional number between 1 and infinity |
If a matching file has existed for at least the specified number
of minutes, a problem is generated.
|
timemax |
optional number between 1 and infinity |
If a matching file has existed for at least the specified number
of minutes, ignore timewarn and timeprob.
|
countwarn |
optional relation, not reg/regv |
Count the number of files matched. If the count matches the
relation specified, a warning is generated and no further tests
are performed.
|
countprob |
optional relation, not reg/regv |
Count the number of files matched. If the count matches the
relation specified, a problem is generated and no further tests
are performed.
|
name |
string list |
File(s) to examine. Files may also be specified with regular
expressions. If no files match the regular expression, the
module will return success.
|
matchone |
optional string, one of 'newest' or 'oldest' |
Test only one file, even if multiple files are named or matched.
Testing is only done on the file with the requested characteristic.
|
Description
The filetest module performs a variety of tests on files.
It must be run via a transport module
unless the files to be tested are on the scheduler host. Details of
the tests performed are in the argument specification, above.
A failure of the grep or type tests will generate a problem, unless
another test has generated a warning, in which case a warning will
be generated.
To use the filetest module to monitor logfiles, use of the
check keyword result
text significant is recommended.
Examples
- To test if a file exists and is being updated frequently:
module filetest {
op all
type f
timewarn 5
timeprob 15
name /var/run/tick
}
via remote
- To test if a batch job completed successfully:
module filetest {
op all
type f
grep reg[^DONE]
name /batch/status
}
via remote
- To check for errors in an output file:
module filetest {
op any
type F
grep regv[^ERROR]
name /batch/output
}
via remote
- To look for .rhosts files:
module filetest {
op all
type F
name /export/home/.*/\.rhosts
name /\.rhosts
}
via remote
- To look for outgoing mail backups (or, use the mailq module):
module filetest {
op all
countprob gt[1000]
name /var/spool/mqueue/df.*
}
via remote
- To test that backup files are being generated regularly:
module filetest {
op all
timeprob 1440
name /db/backups/backup-.*
matchone newest
}
via remote
- To monitor /var/log/authlog for failed login attempts:
module filetest {
op any
type F
grep regv[^failed login]
name /var/log/authlog
showline yes
}
via remote
result text significant
If failed login attempts are found, the module will report them,
and presumably the AlertPlan in effect will start queuing alerts.
Since logfiles are rotated relatively infrequently, there is not
an obvious way to "clear" the problem.
The recommended approach is instead to acknowledge the problem.
When the logfile is rotated, the check will clear, and so will
the acknowledgement. However, if another failed login attempt
occurs, the text description returned by the check will change
(even though the module will still be returning
MODEXEC_PROBLEM), and the result text
significant keyword will tell the scheduler to clear the
existing acknowledgement, and alerting will resume.
Design Errors
This module is very complicated and hard to understand.
$Date: 2006/11/19 19:04:25 $
$Revision: 0.10 $
|
keywords
countprob
countwarn
grep
matchone
name
op
showline
timemax
timeprob
timewarn
type
|