I recall my difficulties (many years ago), when first incorporating
logging, working out what was a "good" logging configuration. I would have
really appreciated a good out-of the box default.
Now I think that the out-of-the box default should be
* A root logger set to INFO
* A rolling appender
I seriously doubt there is a way to create a single “default” configuration.
We could create a few though. For example, if you are running in a
Kubernetes environment you almost certainly want to log JSON to the
console (as much as I hate doing that). A better long term approach would
be to
Structured logging can look like syslog, JSON, or even like a properties file
(for each event). The idea being that instead of merely a log string, there are
key/value pairs to better detail the state being logged.
—
Matt Sicker
> On Jun 13, 2022, at 13:20, Gary Gregory wrote:
>
> Let me
Let me relate the path we took with some of our products. Ages ago, we
started by logging just to the console, then customers would ask for help
and we'd ask for logs, sometimes we got back a copy-paste, other times a
screenshot, nothing helpful, so we then gave the users steps to enable file
Hey all, I was thinking we should figure out a more appropriate default
configuration for 3.0. One idea I have would be to use a structured format by
default along with more emphasis on using either audit events or messages to
log structured data more directly.
Besides that, there are other
