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
