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
