This documents describes a proposal for a framework ("Logmanager") to provide extended and configurable logging mechanisms to Zope. Most of the ideas are based on Chris McDonough's EventLogging product for Zope.

Idea

• seperation of the Logmanager implementation and the users/administrators view through Zope

Framework

The logmanager handles with several kinds of objects:

• Subsystems: subsystems are user- or system defined identifiers for particular components.
• Targets: target objects represent logging destinations like log files in the filesystem, syslog-like destinations, network logging via TCP/UDP...
• Rules: rules define how incoming logging messages are filtered or routed to the different targets. A rule applies usually to one or more targets. Every rule has one or more rule objects that define the filter aspect of the rule.
• Ruleobjects: a rule object defines a filter for one rule. The rule object typically contains a regular expression, values.... that are matched in someway against the corresponding value of the logging message that is applied against the current rule.

Preliminary API

class LogManager:

register_target(targetName,targetType,...configuration options) unregister_target(targetName)

register_subsystem(subsystem) unregister_subsystem(subsystem)

register_rule(rulename,targets,ruleobjs) unregister_rule(rulename)

log(subsystem,serv,summary,detail,error)

The different target types are handled through instances of the subclass Target. The superclass Target implements all stuff that is independant of the target to be used (log output formating...). The target specific output of the formatted logging string to the right destination is done in the instance of the specialized subclass.

Example

L=LogManager()

# Register two subsystems

1. register_subsystem("subsystem1")
2. register_subsystem("subsystem2")

# register a file logging target

l1=L.register_target(myfile,file,fp=open("xxx.log","w"))

# register a console logging target

l2=L.register_target(mycon, console)

# register a syslog target

l3=L.register_target(syslog,sysLog)

# Log everything for subsystem1+2 to file,console when severity > 1

1. register_rule("i log all rule",["myfile","mycon"], SS_RO("subsystem1","subsystem2"),SV_RO(">1"))

# Log for subsystem 'xx" all messages to file,console if severity <100

1. register_rule("rule 1",["myfile","mycon"], SS_RO("xx"),SV_RO("<100"))

# Log for subsystem 'subsystem1" all messages to syslog if 100

1. register_rule("rule 2",["syslog"], SS_RO("subsystem1"),SV_RO(">100","<300"))
2. register_rule("rule 3",["syslog"], SS_RO("subsystem2"),SV_RO(">100"))
3. log("subsystem1",120,"test summary","xxxijfsjd l;ewhjr ljkew",(None,))
4. log("subsystem2",20,"test summary","xxxijfsjd l;ewhjr ljkew",(None,))

This example shows that register_rule() takes one or more rule objects. Here: SS_RO "SubSystem_RuleObject" and SV_RO "SeVerity_RuleObject". Rule objects have only one method matches(). This method matches the corresponding value from the logging message against all conditions passed through the constructor (logical AND). When a rule has more then one rule object all results of single matches() calls for every single rule object are ANDed.

Rule engine

The rule engine is reponsible to determine which rules apply to a log() call. Chris' BetterLogging product applies all rules against the logging messages and collects the rules targets that match. Some other approaches are possible. The choice for the semantics of the rule engine should be driven (IMO) by the user requirement to understand how the the rule engine works.

Integration with Zope

This framework should be mostly independant of Zope. Such a logging infrastructure might become very complex. Different users and administrators have different requirements to such a logging component:

• easy-to-use and easy-to-understand: one should easily understand what the rules are doing
• different views on the logmanager: view-by-subsystem, view-by-target ....

The logmanager must provide all neccessary functions to fullfill these requirements.