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 <boa...@gmail.com> 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
