[Zope] running 2.7 w/out daemon manager

[Chris McDonough]

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.