UltrosBot/Ultros

Logging changes

Opened this issue · 7 comments

gdude2002 commented

As requested..

  • Add support for prefix-grouped loggers
    • First off, these need to be able to share logfiles
    • After that, need to look into full inheritance

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/25783132-logging-changes?utm_campaign=plugin&utm_content=tracker%2F269930&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F269930&utm_medium=issues&utm_source=github).
rakiru commented

Solution: revert logbook

gdude2002 commented

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.

rakiru commented

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.

gdude2002 commented

Define "inheritance" - One thing I like about logbook is the stack of handlers model it does. Would it be similar to that?

rakiru commented

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.

gdude2002 commented

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?

rakiru commented

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.