SrvReport is a simple and featurefull server monitoring and reporting
system. It can send every day a mail with the latest state of the
server including:
The email report will be in HTML (mime with graphics) and text-only format. It is primarily designed for admins who has a server on a remote location and who wants to know what is going on, without always looking at some log-files. Additional feature:
|
Here is a full mail-example |
http://sourceforge.net/projects/srvreport/
Releases can be found here.
Sometimes SF has some problems with the download. If this happens you can also download it from here
linux:~ # wget http://osdn.dl.sourceforge.net/sourceforge/srvreport/srvreport-x.xx.tgz
linux:~ # tar xzfv srvreport-x.xx.tgz
linux:~ # cd srvreport-x.x.x/bin
1-46/15 * * * * /root/srvreport-x.xx/bin/srvreport.pl
bin/srvreport.conf
.
The configuration is very easy. There are only a few global
settings and then you just need to specify which "modules" you want to use.
mailAddr
: Enter here your destination mail address.
order
: Here you can specify in which order the report is generated
Reports are generated via "modules". This are perl modules which implement the report generation for a specific task. In the actual state, the following report-modules are already available.
Each module config section starts with the names in square brackets: [name]
This name is also used in the order
setting under global settings.
In the following each section must contain at least the following keys:
module
: The name of the module (e.g. LogReport, TrafficReport, HttpdReport, ...)
description
: This name will be display in the summary and the headlin for the section in the mail
With this report-module you can simply show any kind of log-entries
or outputs from some command in your reports.
I use it for reporting of
server warnings,
FTP-log entries,
a list of the logins (via /usr/bin/last
-commandentries
and for
checking of rootkits (via chkrootkit).
The configuration is very flexible. It contains the following entries:
%%YYYY
: Year of report
%%MM
: Month (with two decimal) of report
%%mm
: Month (with one or two decimal) of report
%%DD
: Day (with two decimal) of report
%%dd
: Day (with one or two decimal) of report
1
then the whole file is processed
against the pattern
or regex
(if specified).
If this is not set or set to 0, then it is tried to check against the pattern which contains a "%timex" key.
And only the lines which contains the actual date of the report is used.
[FTPLogs]
module = LogReport
description = FTP-Logs
file = /var/log/xferlog
pattern = %o %time1
Here is a more complete example for an configurationWith this you can analyse web-server logfiles (like apache logfiles).
One problem of analysing log files is logrotate
.
To overcome this I used an piplog.pl
for the apache server.
With this pipelog it is possible to create an logfile for every day without
restarting or reloading the web server. This logfile can now be analysed (if the
day is over) and afterwords deleted.
The apache pipelog.pl
is also included in this release (in
the bin
directory).
If you want to use this, you just need to change the /etc/httpd/httpd.conf
and add the following entries (if you have vhosts):
LogFormat "%v \"%{Host}i\" %h %t \"%r\" %>s %b" srvreport
CustomLog |/root/srvreport-x.xx/bin/pipelog.pl srvreport
You also can use any kind of LogFormat
. You then only have to change
the default pattern string in the srvreport.conf
files.
[WebServer]
module = HttpdReport
description = Web-Server
file = /var/log/httpd/srvreport_%%YYYY-%%MM-%%DD
wholeFile = 1
showHTTPStatus = 1
pattern = %o %"vhost %o %time3 %"o %state %bytes
Here is a more complete example for an configuration/proc/net/dev
file is used. It reports
in/out traffic since system boot. All values are read every 15 minutes and are stored in
a separate file in data
directory. This file is then read right
after midnight when the report is generated. Afterwords, this file is deleted.
[Traffic]
module = TrafficReport
description = Traffic report
file = /proc/net/dev
interface = eth0:
pattern = %interface %in %o %o %o %o %o %o %o %out
Here is a more complete example for an configuration/usr/bin/uptime
command. This is read as "normal" file via
the "pipe" symbol (|) at the end. To find the correct value for the 15 minute CPU usage,
a regular expression is ueed.
[CPUUsage]
module = CPUReport
description = CPU Usage
file = /usr/bin/uptime |
regex = load average:\s+\d\.\d\d,\s+\d\.\d\d,\s+(\d\.\d\d)
Here is a more complete example for an configuration/etc/mail
.
[Postfix]
module = PostfixReport
description = Postfix
file = /var/log/mail
pattern = %time2
# with the following you can specify the report(s) that will be
# generated from the mail-log
# You can combine the values to get multiple statistics
# Bit 0 => 1: Overview
# Bit 1 => 2: Detailed list with all mail-IDs
# Bit 2 => 4: Grouped by "to"
# Bit 3 => 8: Popper-analyze
# Bit 4 => 16: Reject-report
# Bit 5 => 32: Graphical report with #Msgs / bytes per hour
# Bit 6 => 64: Table Report with #Msgs / bytes per hour
# Default is 1+4+8+16+32+64=125
mailReportType = 125
Here is a more complete example for an configuration%o
: Unused data
%"o
: Unused data surrounded by quotation marks
%time1
: Date/Time format of the kind May 18 09:05:21 2003
%time2
: Date/Time format of the kind May 18 09:05:21
%time3
: Date/Time format of the kind [07/Jan/2004:00:08:44 +0100]
( +0100
is optional)
%time5
: Date/Time in the form of 2004-01-30 15:34:11
%time4
: Date format of the kind May 18
%vhost
: Marks an virual host
%"vhost
: Same as %vhost
expect it is surrounded by quotation marks
%bytes
: Contains the number of bytes
%out
: Contains the number of bytes sent
%in
: Contains the number of bytes received
%state
: Contains the state (e.g. HTTP state code)
%interface
: Contains the interface string (e.g. for TrafficReport)
If you want to analyse some system log files, then you might run into the problem that this file was
just rotated via logrotate
. The effect is that you loose some info.
logrotate.d
via postrotate
or prerotate
CustomLog
and use my
piplog.pl
to do my own logging for every day. This file is then deleted
if the report is generated.
This software has a OO-design, so it can be easy extended by other programmers.
You can either derive your report-module from BaseReport
or
from BaseFileReport
(which is usualy the case)