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 enhance K8S to support virtual files that take the place of the console.
If you are shipping a product you could a) log to local files b) route the logs back to a logging service you host. But that probably only scratches the surface. After all we have a lot of Appenders and I am sure there a lot more in the wild. Ralph > On Jun 13, 2022, at 11: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
