Search Exchange
Search All Sites
Login
New Listingscheck_log3.pl
Current Version
3.5a
Last Release Date
2013-04-11
Compatible With
- Nagios 2.x
- Nagios 3.x
- Nagios XI
- Nagios Fusion
Owner
E-mail
License
GPL
Hits
21545
Files:
| File | Description |
|---|---|
| check_log3.pl | Plugin code (Perl) |
| check_log3.exe | Standalone Windows executable |
| check_customlog.pl | Wrapper script for easier configuration |
| parameters.txt | Wrapper script configuration examples |
Log file regular expression based parser plugin for Nagios.
Written by Aaron Bostick (abostick@mydoconline.com)
Rewritten by Peter Mc Aulay and Tom Wuyts
The -a feature was contributed by Ian Gibbs
Released under the terms of the GNU General Public Licence v2.0
Last updated 2013-04-11 by Peter Mc Aulay
Thanks and acknowledgements to Ethan Galstad for Nagios and the check_log plugin this is modeled after.
Tested on Linux, Windows, AIX and Solaris.
Usage: check_log3.pl --help
*** Description ***
This plugin will scan arbitrary text files looking for regular expression matches. A temporary file is used to store the seek byte position of the last scan. This file will be created automatically.
The search pattern can be any RE pattern that perl's s/// syntax accepts. The search patterns can be read from a file, one per line; the lines will be combined into a regexp of the form 'line1|line2|line3|...'.
A negation pattern can be specified, causing the plugin to explicitly not match on lines that match it, even if they do match the search pattern. Alternatively, the ignore patterns can be read from a file (again, one per line). This is for badly behaved applications that produce lots of error messages when running "normally" (certain Java apps come to mind). You can use either -n or -f, but not both. If both are specified, -f will take precedence.
Note that a bad regexp might case an infinite loop, so set a reasonable plugin time-out in Nagios.
Patterns can be either case sensitive or case insensitive. The -i option controls case sensitivity for both search and ignore patterns.
It is also possible to just raise an alert if the log file was not written to since the last check (using -d or -D). You can use these options alone or in combination with pattern matching.
Optionally the plugin can execute a block of Perl code on each matched line, to further affect the output (using -e or -E). The code should be enclosed in curly brackets (and probably quoted) if it's more than one statement. It will be executed as a Perl 'eval' block and the matched line will be passed to it as $_. It is expected to return a value. The eval code will also have access to check_log3.pl's internal variables.
The most useful of these are probably:
- $parse_out, which if set will replace the saved line for the current match (provided the eval block returns 1). If this is not set, the default is used, which is the input line itself.
- $perfdata, which if set will replace the default performance data output of number of lines found/lines matched.
- @line_buffer, which is an array of the lines preceding the current match (if the -C option is used).
Return code:
- If the code returns non-zero, it is counted towards the alert threshold.
- If the code returns 0, the line is not counted against the threshold. (It's still counted as a match, but for informational purposes only.)
You can use either -e or -E, but if you use both, -E will take precedence.
Note: -e and -E are advanced features and potentially dangerous!
*** Return codes ***
This plugin returns OK when a file is successfully scanned and no pattern matches are found.
It returns WARNING or CRITICAL if pattern matches were found; the -w and -c options determine how many lines must match before an alert is raised.
If an eval block is defined (via -e or -E) a line is only counted if it both matches the pattern and the custom code returns a non-zero result for that line.
If the thresholds are expressed as percentages, the thresholds are taken to mean the percentage of lines in the input that match (match / total * 100). If -e is used, the percentage of matched lines that also match the parsing condition is taken, rather than the total number of lines in the input.
By default, the plugin returns WARNING if one match was found.
The plugin returns WARNING if the -d option is used, and the log file hasn't grown since the last run. Likewise, if -D is used, it will return CRITICAL instead. Take care that the time between service checks is less than the minimum amount of time your application writes to the log file when you use these options.
If the --ok option is used, the plugin will always return OK unless an error occurs and will ignore any thresholds. This can be useful if you use this plugin only for its log parsing functionality, not for alerting (e.g. to just plot a graph of values extracted from the log file).
The plugin always returns CRITICAL if an error occurs, such as if a file is not found or in case of a permissions problem or an I/O error.
*** Output ***
By default, the last line matching the pattern is returned in the output along with the pattern count.
If -1 is used, the first line matching the pattern is returned. Use this if you want to be notified of every single match. Note: only one match will be returned per check, so you'll want to adjust your check interval accordingly (i.e. make it smaller than usual).
If custom Perl code is run on matched lines using -e, it may modify the output via $parse_out (and only this way; do not use 'print' or related functions).
Use the -a option to output all matching lines instead of just the last matching one. Note that Nagios will only read the first 4 KB of data that a plugin returns, and that most NRPE agents even has a 1KB output limit.
Use the -C option to return some lines of "context" before and/or after the matched line. Prefix the number with - to return extra lines only before the matched line (like "grep -B"), with + to return extra lines only after the matched line (like "grep -A"), or with nothing to return extra lines both before and after the match (like "grep -C").
Note: lines returned as context are not parsed with -e or -E, nor is any context preserved if you override the output by modifying $parse_out. If you want to modify the output while using -C, modify @line_buffer instead.
If you use -a and -C together, the plugin will output "---" between sections of matched lines and their context.
*** Performance data ***
The number of matching lines is returned as performance data (key = "lines"). If -e is used, the number of matching lines is also returned (key = "parsed"). Custom eval code can change the perfdata output by modifying the value of the $perfdata variable, for when you want to graph the actual figures in the log file rather than the number of lines found.
*** Nagios service check configuration notes ***
1. You must always supply a different seek file for each service check that you define - even if the checks are reading the same log file. Otherwise one check will start reading where another left off, which is likely not what you want (especially due to the way Nagios schedules service checks, the order in which they run can be unpredictable).
2. The notification options for the service should always be set to not notify you of recoveries for the check. Since pattern matches in log file will only be reported once, "recoveries" are not really meaningful.
3. The maximum check attempts value for the service should always be 1, to prevent Nagios from retrying the service check (the next time the check is run it will not produce the same results). Otherwise you will not receive a notification for every match.
*** A few simple examples ***
Return WARNING if errors occur in the system log, but ignore the ones from the NRPE agent itself:
check_log3.pl -l /var/log/messages -s /tmp/log_messages.seek -p '[Ee]rror' -n nrpe
Return WARNING if more than 10 logon failures logged since last check, or CRITICAL if there are more than 50:
check_log3.pl -l /var/log/auth.log -s /tmp/auth.seek -p 'Invalid user' -w 10 -c 50
Return WARNING if more than 10 errors logged or CRITICAL if the application stops writing to the log file altogether:
check_log3.pl -l /var/log/heartbeat.log -s /tmp/heartbeat.seek -p ERROR -w 10 -D
*** Some avanced examples ***
Return WARNING and print a custom message if there are more than 50 lines in a CSV formatted log file where column 7 contains a value over 4000:
check_log3.pl -l processing.log -s processing.seek -p ',' -w 50 -e
'{
my @fields = split(/,/);
if ($fields[6] > 4000) {
$parse_out = "Processing time for $fields[0] exceeded: $fields[6]n";
return 1
}
}'
Note: in nrpe.cfg this will all have to be put on one line. It will be more readable if you put the parser code in a separate file and use -E.
Return WARNING if a stack trace is found and output the preceding 10 lines, if at least one other string is found there, and report every match:
check_log3.pl -l console.log -s console.seek -p '^Exception Stack Trace' -1 -C -10 -e 'return 1 if grep(/MyApplGetAccountNumber/, @line_buffer);'
Written by Aaron Bostick (abostick@mydoconline.com)
Rewritten by Peter Mc Aulay and Tom Wuyts
The -a feature was contributed by Ian Gibbs
Released under the terms of the GNU General Public Licence v2.0
Last updated 2013-04-11 by Peter Mc Aulay
Thanks and acknowledgements to Ethan Galstad for Nagios and the check_log plugin this is modeled after.
Tested on Linux, Windows, AIX and Solaris.
Usage: check_log3.pl --help
*** Description ***
This plugin will scan arbitrary text files looking for regular expression matches. A temporary file is used to store the seek byte position of the last scan. This file will be created automatically.
The search pattern can be any RE pattern that perl's s/// syntax accepts. The search patterns can be read from a file, one per line; the lines will be combined into a regexp of the form 'line1|line2|line3|...'.
A negation pattern can be specified, causing the plugin to explicitly not match on lines that match it, even if they do match the search pattern. Alternatively, the ignore patterns can be read from a file (again, one per line). This is for badly behaved applications that produce lots of error messages when running "normally" (certain Java apps come to mind). You can use either -n or -f, but not both. If both are specified, -f will take precedence.
Note that a bad regexp might case an infinite loop, so set a reasonable plugin time-out in Nagios.
Patterns can be either case sensitive or case insensitive. The -i option controls case sensitivity for both search and ignore patterns.
It is also possible to just raise an alert if the log file was not written to since the last check (using -d or -D). You can use these options alone or in combination with pattern matching.
Optionally the plugin can execute a block of Perl code on each matched line, to further affect the output (using -e or -E). The code should be enclosed in curly brackets (and probably quoted) if it's more than one statement. It will be executed as a Perl 'eval' block and the matched line will be passed to it as $_. It is expected to return a value. The eval code will also have access to check_log3.pl's internal variables.
The most useful of these are probably:
- $parse_out, which if set will replace the saved line for the current match (provided the eval block returns 1). If this is not set, the default is used, which is the input line itself.
- $perfdata, which if set will replace the default performance data output of number of lines found/lines matched.
- @line_buffer, which is an array of the lines preceding the current match (if the -C option is used).
Return code:
- If the code returns non-zero, it is counted towards the alert threshold.
- If the code returns 0, the line is not counted against the threshold. (It's still counted as a match, but for informational purposes only.)
You can use either -e or -E, but if you use both, -E will take precedence.
Note: -e and -E are advanced features and potentially dangerous!
*** Return codes ***
This plugin returns OK when a file is successfully scanned and no pattern matches are found.
It returns WARNING or CRITICAL if pattern matches were found; the -w and -c options determine how many lines must match before an alert is raised.
If an eval block is defined (via -e or -E) a line is only counted if it both matches the pattern and the custom code returns a non-zero result for that line.
If the thresholds are expressed as percentages, the thresholds are taken to mean the percentage of lines in the input that match (match / total * 100). If -e is used, the percentage of matched lines that also match the parsing condition is taken, rather than the total number of lines in the input.
By default, the plugin returns WARNING if one match was found.
The plugin returns WARNING if the -d option is used, and the log file hasn't grown since the last run. Likewise, if -D is used, it will return CRITICAL instead. Take care that the time between service checks is less than the minimum amount of time your application writes to the log file when you use these options.
If the --ok option is used, the plugin will always return OK unless an error occurs and will ignore any thresholds. This can be useful if you use this plugin only for its log parsing functionality, not for alerting (e.g. to just plot a graph of values extracted from the log file).
The plugin always returns CRITICAL if an error occurs, such as if a file is not found or in case of a permissions problem or an I/O error.
*** Output ***
By default, the last line matching the pattern is returned in the output along with the pattern count.
If -1 is used, the first line matching the pattern is returned. Use this if you want to be notified of every single match. Note: only one match will be returned per check, so you'll want to adjust your check interval accordingly (i.e. make it smaller than usual).
If custom Perl code is run on matched lines using -e, it may modify the output via $parse_out (and only this way; do not use 'print' or related functions).
Use the -a option to output all matching lines instead of just the last matching one. Note that Nagios will only read the first 4 KB of data that a plugin returns, and that most NRPE agents even has a 1KB output limit.
Use the -C option to return some lines of "context" before and/or after the matched line. Prefix the number with - to return extra lines only before the matched line (like "grep -B"), with + to return extra lines only after the matched line (like "grep -A"), or with nothing to return extra lines both before and after the match (like "grep -C").
Note: lines returned as context are not parsed with -e or -E, nor is any context preserved if you override the output by modifying $parse_out. If you want to modify the output while using -C, modify @line_buffer instead.
If you use -a and -C together, the plugin will output "---" between sections of matched lines and their context.
*** Performance data ***
The number of matching lines is returned as performance data (key = "lines"). If -e is used, the number of matching lines is also returned (key = "parsed"). Custom eval code can change the perfdata output by modifying the value of the $perfdata variable, for when you want to graph the actual figures in the log file rather than the number of lines found.
*** Nagios service check configuration notes ***
1. You must always supply a different seek file for each service check that you define - even if the checks are reading the same log file. Otherwise one check will start reading where another left off, which is likely not what you want (especially due to the way Nagios schedules service checks, the order in which they run can be unpredictable).
2. The notification options for the service should always be set to not notify you of recoveries for the check. Since pattern matches in log file will only be reported once, "recoveries" are not really meaningful.
3. The maximum check attempts value for the service should always be 1, to prevent Nagios from retrying the service check (the next time the check is run it will not produce the same results). Otherwise you will not receive a notification for every match.
*** A few simple examples ***
Return WARNING if errors occur in the system log, but ignore the ones from the NRPE agent itself:
check_log3.pl -l /var/log/messages -s /tmp/log_messages.seek -p '[Ee]rror' -n nrpe
Return WARNING if more than 10 logon failures logged since last check, or CRITICAL if there are more than 50:
check_log3.pl -l /var/log/auth.log -s /tmp/auth.seek -p 'Invalid user' -w 10 -c 50
Return WARNING if more than 10 errors logged or CRITICAL if the application stops writing to the log file altogether:
check_log3.pl -l /var/log/heartbeat.log -s /tmp/heartbeat.seek -p ERROR -w 10 -D
*** Some avanced examples ***
Return WARNING and print a custom message if there are more than 50 lines in a CSV formatted log file where column 7 contains a value over 4000:
check_log3.pl -l processing.log -s processing.seek -p ',' -w 50 -e
'{
my @fields = split(/,/);
if ($fields[6] > 4000) {
$parse_out = "Processing time for $fields[0] exceeded: $fields[6]n";
return 1
}
}'
Note: in nrpe.cfg this will all have to be put on one line. It will be more readable if you put the parser code in a separate file and use -E.
Return WARNING if a stack trace is found and output the preceding 10 lines, if at least one other string is found there, and report every match:
check_log3.pl -l console.log -s console.seek -p '^Exception Stack Trace' -1 -C -10 -e 'return 1 if grep(/MyApplGetAccountNumber/, @line_buffer);'
Reviews (0)
Be the first to review this listing!
