Yes, you can disambiguate the log entries as necessary by prepending some literal string to the message or whatever. The default event log handler format string is "------\n%(asctime)s %(message)s"; the default access log format string is "%(message)s" (the message includes the time). FWIW, the allowable interpolation values are: %(name)s Name of the logger (logging channel) %(levelno)s Numeric logging level for the message (DEBUG, INFO, WARNING, ERROR, CRITICAL) %(levelname)s Text logging level for the message ("DEBUG", "INFO", "WARNING", "ERROR", "CRITICAL") %(pathname)s Full pathname of the source file where the logging call was issued (if available) %(filename)s Filename portion of pathname %(module)s Module (name portion of filename) %(lineno)d Source line number where the logging call was issued (if available) %(created)f Time when the LogRecord was created (time.time() return value) %(asctime)s Textual time when the LogRecord was created %(msecs)d Millisecond portion of the creation time %(relativeCreated)d Time in milliseconds when the LogRecord was created, relative to the time the logging module was loaded (typically at application startup time) %(thread)d Thread ID (if available) %(message)s The result of record.getMessage(), computed just as the record is emitted - C On Thu, 2004-02-12 at 18:04, Jamie Heilman wrote:
Chris McDonough wrote:
<logger access> level WARN <logfile> path STDOUT format %(message)s </logfile> </logger>
Then you could use multilog to figure out which is which (somehow), and I think all is well.
What is the format directive all about? Can you affect the line as its written to STDOUT with that? If so you could potentialy tag all access logs with some prefix which would make it trivial to seperate them again in multilog using its pattern matching stuff.