node-bunyan

> But if some log message uses an attribute you haven't anticipated in the format definition, there's no way to see it in the pretty-printed output Properties in the log message that are not in the "line-format" are displayed below the message as key-value pairs. As an example, the bunyan[1] log format[2] has a few standard properties that are used in the "line-format" to form the main message. Then, as shown in this test[3] for this log[4], the remaining properties (even ones not mentioned in the format file) are shown underneath. > or filter on it in the UI Since they are part of the message as mentioned above, they can be filtered on. > and no ability to see it in the SQLite virtual table. The "log_raw_text" column in the table can be used to access the original log message from the file. So, you can use the JSON functions in SQLite

Agree with everything you've said, but MDC does have one big drawback: it's only convenient when you're working within a single thread. If you're writing asynchronous code (Scala, Akka, Vert.x etc) then MDC doesn't help you very much. [1] I generally find it easier to have an explicit "context" object and pass that around in an operation, and then log once that context has been built up. If you're lucky, the logging framework will do that for you. Bunyan did this the Right Way from the get go, using `log.child`. [2] [1] https://tersesystems.github.io/blindsight/usage/context.html... [2] https://github.com/trentm/node-bunyan#logchild

That depends on where the ringbuffer is placed. If you're placing the ringbuffer inside an appender, then the appender's encoder will format. However, if the ringbuffer itself is an appender, then you can store the logging events as is until it's time to dump them -- this is the approach in terse-logback [1] Another option is to put the ringbuffer BEFORE sending it to the logging framework, so it's never processed by SLF4J at all. This means that it's more accessible to the application, at the cost of losing the initial timestamp of the logging event. This is the approach taken in Blindsight. [2] Shout out to Bunyan, which is (AFAIK) the only server side logging framework that has ringbuffers out of the box. [3] [1] https://tersesystems.github.io/terse-logback/guide/ringbuffe... [2] https://tersesystems.github.io/blindsight/usage/buff

I would use a json based logger like https://github.com/trentm/node-bunyan or https://github.com/pinojs/pino and use the elk stack which can parse JSON.

This is a node module but the idea can be applied generally (https://github.com/trentm/node-bunyan). Basically you output the logs in the format ops require(Which i assume would be structured) and for devs put a beautifier that parses the logs and prints in the format they require.

See https://github.com/trentm/node-bunyan