1. 3
    1. 4

      I found this is the best and very intuitive and well though out public api when doing structured logging.


      1. 1

        The new standard logger took that as one of their starting points.

    2. 3

      I wish log levels would disappear because nobody can agree on when to use “warning”, “debug”, “info” or “error”. It depends on the audience that is reading the logs. How can a library decide on the log level if it doesn’t have the full context?

      The reason they exist is because of the limitations of old logging systems. With structured logging, we can tag lines with more context. Is it a logic error or a user input error? Who is the audience for the message?

      1. 3

        In a previous workplace, we had our log levels defined as:

        • page on call
        • for the morning (aka log and let someone see it when they’re in the office)
        • informational
        • ddos logging service (aka debug)

        Now a days, I wish people would stop implementing logging at all, and rather use traces, you can get much richer information from then, and can define alerting based on more interesting or complex conditions

      2. 1

        Yeah. It’s a mismatch the person writing the level and the person consuming it can have totally different goals in mind. Dave Cheney argued the only log levels should be info and debug. I think debug needs a further filter so you can say “debug, but only parts the app related to the thing I’m debugging now (a package, a request, whatever)”. Structured logging gives you ways to do that (only show logs with key x=y), but it’s still another step on top, versus saying myapp --log=warn that many apps support.