General logging facility
This module attempts to provide a simple programming API for logging
with a pluggable API for defining where log messages should go.
Programmers call the LOG function to log information.
The LOG function, in turn, calls the write_log method to actually write
logging information somewhere. This module provides a very simple
write_log implementation. It is intended that applications main
programs will replace this method with a method more suited to their needs.
The module provides a register_subsystem method that does nothing, but
provides a hook that logging management systems could use to collect information about subsystems being used.
The module defines several standard severities:
- TRACE=-300
Trace messages
- DEBUG=-200
Debugging messages
- BLATHER=-100
Somebody shut this app up.
- INFO=0
For things like startup and shutdown.
- PROBLEM=100
This isn't causing any immediate problems, but deserves
attention.
- WARNING=100
A wishy-washy alias for PROBLEM.
- ERROR=200
This is going to have adverse effects.
- PANIC=300
We're dead!
Also, looging facilities will normally ignore negative severities.
To plug in a log handler, simply replace the log_write function
with a callable object that takes 5 arguments:
- subsystem
The subsystem generating the message (e.g. ZODB)
- severity
The "severity" of the event. This may be an integer or
a floating point number. Logging back ends may
consider the int() of this valua to be significant.
For example, a backend may consider any severity
whos integer value is WARNING to be a warning.
- summary
A short summary of the event
- detail
A detailed description
- error
A three-element tuple consisting of an error type, value, and
traceback. If provided, then a summary of the error
is added to the detail.
There is a default stupid logging facility that:
swallows logging information by default,
outputs to sys.stderr if the environment variable
STUPID_LOG_FILE is set to an empty string, and
outputs to file if the environment variable
STUPID_LOG_FILE is set to a file name.
Ignores errors that have a severity < 0 by default. This
can be overridden with the environment variable STUPID_LOG_SEVERITY
Imported modules
|
|
import string
import sys
import time
|
Functions
|
|
LOG
format_exception
log_time
register_subsystem
severity_string
stupid_log_write
|
|
LOG
|
LOG (
subsystem,
severity,
summary,
detail='',
error=None,
reraise=None,
)
Log some information
The required arguments are:
- subsystem
The subsystem generating the message (e.g. ZODB)
- severity
The "severity" of the event. This may be an integer or
a floating point number. Logging back ends may
consider the int() of this valua to be significant.
For example, a backend may consider any severity
whos integer value is WARNING to be a warning.
- summary
A short summary of the event
- detail
A detailed description
- error
A three-element tuple consisting of an error type, value, and
traceback. If provided, then a summary of the error
is added to the detail.
- reraise
If provided with a true value, then the error given by
error is reraised.
|
|
format_exception
|
format_exception (
etype,
value,
tb,
limit=None,
delimiter='\\n',
header='',
trailer='',
)
|
|
log_time
|
log_time ()
Return a simple time string without spaces suitable for logging
|
|
register_subsystem
|
register_subsystem ( subsystem )
Register a subsystem name
A logging facility might replace this function to collect information about
subsystems used in an application.
|
|
severity_string
|
severity_string ( severity, mapping={ - 300 : 'TRACE', - 200 : 'DEBUG', - 100 : 'BLATHER', 0 : 'INFO', 100 : 'PROBLEM', 200 : 'ERROR', 300 : 'PANIC', } )
Convert a severity code to a string
|
|
stupid_log_write
|
stupid_log_write (
subsystem,
severity,
summary,
detail,
error,
)
|
|