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 logged to a file in the working directory * Some examples of how to configure named loggers in comments On Tue, Jun 14, 2022 at 4:55 AM Matt Sicker <[email protected]> wrote: > 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 <[email protected]> wrote: > > > > 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 > > logging and they would send us that. These days, most of our products are > > configured out of the box with console and rolling file logging, and the > > only reason we loop with a customer is to get more with debug or trace > > level logging for some loggers. > > > > All of that to say that for us, a sensible default, is a configuration > that > > let's users send us a file or a zipped folder of log files. > > > > I'm worried that something "structured" beyond text or a CSV would be an > > extra complication for support or development to easily "see" what is > > going on > > > > Gary > > > >> On Mon, Jun 13, 2022, 12:57 Matt Sicker <[email protected]> wrote: > >> > >> 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 options we could enable by default that > were > >> added after 2.0 that increase performance. I’d almost be inclined to > >> default to async logging, too, but that might be surprising behavior if > we > >> have to do that based on an optional module at runtime. > >> > >> We could investigate the various best practices everyone has developed > >> over time for parsing and searching logs to use a default layout that > works > >> most efficiently there. For example, timestamps would use a fairly fixed > >> width format (one of the full ISO 8601 formats that doesn’t use the > month > >> name, day name, or time zone name, as those are all varying width), > sorting > >> fields if needed, etc. > >> > >> As a bonus idea, we could also define some useful “standard” keys for > >> ThreadContext like TraceId, SpanId, RequestId, etc. Basically, make it > more > >> obvious that you can enable distributed trace logging without a gigantic > >> OpenTelemetry or Zipkin dependency stack (on the producing side; feel > free > >> to use whatever for collecting the spans). > >> > >> — > >> Matt Sicker >
