Open gdude2002 opened 9 years ago
Solution: revert logbook
A lot of the things Logbook provides are nice, but until it was used it was hard to see how/if it'd suit things, and well, I'm not so sure now. And I can't remember why I decided to use it.
We do still need a logging system; if we're going to plan a new one, let's actually plan it out this time.
So, the plan is to use standard library logging
; it provides everything we need, unlike logbook.
What requirements do we have? Children/inheritance is a native concept in logging
, so that's not an issue. Log rotating is also supported by using a TimedRotatingFileHandler
handler, which the example/default config can be set up with. There are also handlers for SMTP, HTTP, syslog, and some other stuff. Is there anything else we'd want to offer? Personally, all I need is TimedRotatingFileHandler
and inheritance.
Define "inheritance" - One thing I like about logbook is the stack of handlers model it does. Would it be similar to that?
I can configure the plugins
logger to log to plugins.log
or something, then plugins.urls
and plugins.urltools
would also go in there. I could also override plugins.web
to save to web.log
as well as or instead of plugins.log
. It's a tree system, where each node inherits from its parent.
That's a basic example, but logbook doesn't have that concept built in. They have LoggingGroup, but that's a one-level thing (well, you may be able to nest them within each other) and it's defined in code; the logger name has no influence over it, which is silly when loggers are named in an organised tree already.
Ah, yeah, I see, that does make sense.
Can we integrate this with metrics as well? I mean, builtin logging has an exception logging call, right?
We could make a MetricsHandler that submits to metrics, yeah. If you specify it as a handler for the root node, every other logger will get it.
As requested..