Simple logcheck recipe
Applications that generate logfiles inside your buildout can profit from regular, you know, actually checking those logfiles.
Logcheck is a unix utility that can go through your logfiles and that will mail you those lines that you find interesting, provided you configure it right with ignores.
tha.recipe.logcheck provides a simple way of setting up a set of local configuration files for logcheck. To actually use it, z3c.recipe.usercrontab is recommended. A ${logcheck:command} option is available for easy integration.
Detailed documentation
Supported options
The recipe supports the following options:
- logfiles
Logfiles is a list of one or more logfiles that should be handled by the logcheck utility. This parameter is required.
- recipient
One (?TODO: check) email address to serve as recipient of the logcheck emails. This parameter is required.
- ignores
Several optional lines of regex expressions. If a regex matches, the matching line is excluded from the logcheck email.
- subject
Subject used in the email subject. (Note: only part of the subject, logcheck itself appends/prepends the date and so.) Defaults to logfile path instead of the unhelpful “System Events” default of logcheck itself.
Example usage
We’ll start by creating a buildout that uses the recipe:
>>> write('buildout.cfg',
... """
... [buildout]
... parts = logcheck
...
... [logcheck]
... recipe = tha.recipe.logcheck
... logfiles = var/example.log
... recipient = someone@example.com
... subject = my site
... """)
Running the buildout installs a directory structure in parts and var:
>>> print 'start', system(buildout)
start...
Installing logcheck.
logcheck: Created /sample-buildout/var/logcheck
logcheck: Created /sample-buildout/var/logcheck/state
logcheck: Created /sample-buildout/parts/logcheck
logcheck: Created /sample-buildout/parts/logcheck/cracking.d
logcheck: Created /sample-buildout/parts/logcheck/cracking.ignore.d
logcheck: Created /sample-buildout/parts/logcheck/violations.d
logcheck: Created /sample-buildout/parts/logcheck/violations.ignore.d
logcheck: Created /sample-buildout/parts/logcheck/ignore.d.paranoid
logcheck: Created /sample-buildout/parts/logcheck/ignore.d.server
logcheck: Created /sample-buildout/parts/logcheck/ignore.d.workstation
<BLANKLINE>
>>> ls('var/logcheck')
d state
>>> ls('parts/logcheck')
d cracking.d
d cracking.ignore.d
d ignore.d.paranoid
d ignore.d.server
d ignore.d.workstation
- logcheck.conf
- logcheck.logfiles
d violations.d
d violations.ignore.d
>>> ls('bin')
- buildout
The logfiles config file lists the logfiles:
>>> cat('parts/logcheck/logcheck.logfiles')
/sample-buildout/var/example.log
The generic config file lists the right directories:
>>> cat('parts/logcheck/logcheck.conf')
REPORTLEVEL="workstation"
SENDMAILTO="someone@example.com"
FQDN=0
RULEDIR="/sample-buildout/parts/logcheck"
LOCKFILE="/sample-buildout/var/logcheck/lock"
LOGFILES_LIST="/sample-buildout/parts/logcheck/logcheck.logfiles"
STATEDIR="/sample-buildout/var/logcheck/state"
EVENTSSUBJECT="my site"
If you don’t specify a subject, the default fallback is the filename that is checked (added in 0.4):
>>> write('buildout.cfg',
... """
... [buildout]
... parts = logcheck
...
... [logcheck]
... recipe = tha.recipe.logcheck
... logfiles = var/example.log
... recipient = someone@example.com
... """)
>>> print 'start', system(buildout)
start Uninstalling logcheck.
Installing logcheck.
<BLANKLINE>
>>> cat('parts/logcheck/logcheck.conf')
REPORTLEVEL="workstation"
SENDMAILTO="someone@example.com"
FQDN=0
RULEDIR="/sample-buildout/parts/logcheck"
LOCKFILE="/sample-buildout/var/logcheck/lock"
LOGFILES_LIST="/sample-buildout/parts/logcheck/logcheck.logfiles"
STATEDIR="/sample-buildout/var/logcheck/state"
EVENTSSUBJECT="/sample-buildout/var/example.log"
Specifiying two logfiles is possible
>>> write('buildout.cfg',
... """
... [buildout]
... parts = logcheck
...
... [logcheck]
... recipe = tha.recipe.logcheck
... logfiles =
... var/example.log
... var/emergency.log
... recipient = someone@example.com
... subject = my site
... """)
>>> print 'start', system(buildout)
start Uninstalling logcheck.
Installing logcheck.
<BLANKLINE>
>>> cat('parts/logcheck/logcheck.logfiles')
/sample-buildout/var/example.log
/sample-buildout/var/emergency.log
Strategy
The logcheck setup done by this recipe is very simple. The needed logcheck directories are created, but mostly left empty. This means that all logfile messages are, in principle, mailed.
This is obviously not intended. Therefore the ignore.d.workstation directory has one file with ignore regex’s if you specified them.
>>> ls('parts/logcheck/ignore.d.workstation')
We specify a regex:
>>> write('buildout.cfg',
... """
... [buildout]
... parts = logcheck
...
... [logcheck]
... recipe = tha.recipe.logcheck
... logfiles = var/example.log
... recipient = someone@example.com
... ignores =
... ^.+INFO.*
... """)
>>> print 'start', system(buildout)
start...
Uninstalling logcheck.
Installing logcheck.
logcheck: Writing file with 1 ignore patterns: /...station/logcheck-ignores
<BLANKLINE>
>>> ls('parts/logcheck/ignore.d.workstation')
- logcheck-ignores
>>> cat ('parts/logcheck/ignore.d.workstation/logcheck-ignores')
^.+INFO.*
Logcheck is supposed to be called from a cronjob. The recipe provides an option that lists the correct command that can be used from other recipes:
>>> write('crontab', '')
>>> write('buildout.cfg',
... """
... [buildout]
... parts = logcheck crontab
...
... [logcheck]
... recipe = tha.recipe.logcheck
... logfiles = var/example.log
... recipient = someone@example.com
... ignores =
... ^.+INFO.*
...
... [crontab]
... recipe = z3c.recipe.usercrontab
... times = */5 * * * *
... command = ${logcheck:command}
... readcrontab = cat ${buildout:directory}/crontab
... writecrontab = cat > ${buildout:directory}/crontab
...
... """)
>>> print 'start', system(buildout)
start...
Updating logcheck.
Installing crontab.
>>> cat('crontab')
<BLANKLINE>
# Generated by /sample-buildout [crontab]
*/5 * * * * /usr/sbin/logcheck -c /sample-buildout/parts/logcheck/logcheck.conf
# END /sample-buildout [crontab]
<BLANKLINE>
Credits
Created by Reinout van Rees at The Health Agency
Changelog for tha.recipe.logcheck
1.1 (2009-12-18)
Documentation and license update. [reinout]
Adjusted tests for change in crontab recipe. [reinout]
1.0 (2009-05-27)
Cleaned up code a bit (bootstrap.py in proper location and so). [reinout]
0.4 (2009-05-22)
Default subject is now the full pathname of the first logfile. [reinout]
Little bit more testing. [reinout]
0.3 (2009-04-21)
Allow option (‘subject’) of setting the subject. (Well, part of the subject at least). [reinout]
0.2 (2009-03-30)
Fixed typo in ignore file generation. [reinout]
0.1 (2009-03-17)
Added “command” option for use in crontab recipe. [reinout]
Creating logcheck directories and configfiles in var/ and parts/. [reinout]
Created recipe with ZopeSkel [reinout]
Metadata
Release files for tha.recipe.logcheck 1.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| tha.recipe.logcheck-1.1.tar.gz | 9.3 kB | Without provenance | Details for tha.recipe.logcheck-1.1.tar.gz |
Release files / tha.recipe.logcheck-1.1.tar.gz
| Download URL | tha.recipe.logcheck-1.1.tar.gz |
|---|---|
| Size | 9.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
6d3210156808b492f86f2d3f22802b27ec5c397825790b91ad2ba211f97f339c
|
|
BLAKE2b-256 checksum How to use checksums |
6b78c743b605bbfdf60482eba233ead32d24a6332c120cbc670015aa4a0a9a6d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for tha.recipe.logcheck 1.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.