Log polish #27
Log polish #27
Conversation
during discussion, several advantages were noted: * easy to grep * easy to integrate with text processing other tools (log collectors etc) * better use of screen space
* fixed-width level, time and message makes for nice columns * colorize keys according to log level * remove brackets around stuff (already conveyed by columns) * quote values with spaces in them (like logfmt, allows parsing k/v easily
|
A nitpick. Both 5-letter and 3-letter log levels seem nicer to me than 4-letters: |
chronicles/log_output.nim
Outdated
| of NONE: (fgWhite, false) | ||
|
|
||
| template appendLogLevelMarker(r: var auto, lvl: LogLevel, align: bool) = | ||
| let (color, bright) = levelToStyle(lvl) |
There was a problem hiding this comment.
You can still have when r.colors != NoColors: here.
There was a problem hiding this comment.
can, but repeats color check from fgColor etc - not better to keep all in one place?
| # no good way to tell how much padding is going to be needed so we | ||
| # choose an arbitrary number and use that - should be fine even for | ||
| # 80-char terminals | ||
| let padding = static(repeat(' ', if pad: 42 - min(42, name.len) else: 0)) |
There was a problem hiding this comment.
likewise, compile error
chronicles/log_output.nim
Outdated
|
|
||
| template appendLogLevelMarker(r: var auto, lvl: LogLevel, align: bool) = | ||
| let (color, bright) = levelToStyle(lvl) | ||
| let lvlString = |
There was a problem hiding this comment.
no luck:
/home/arnetheduck/status/nim-chronicles/chronicles/log_output.nim(309, 9) Error: internal error: transformConstSection
|
|
||
| fgColor(r, propColor, false) | ||
| let (color, bright) = levelToStyle(r.level) |
There was a problem hiding this comment.
You can add when r.colors != NoColors: above this line.
chronicles/options.nim
Outdated
| # default is textlines - single-line format is good for interop with | ||
| # text processing tools like grep and logstash, good use of screen | ||
| # real estate | ||
| else: parseSinksSpec "textlines" |
There was a problem hiding this comment.
Since the team decided on this change, that's OK, but I'll voice few more arguments for the former textblocks choice:
-
The argument that log systems are already optimized to deal with one record per-line is not that strong IMO, because most systems already had to deal with stack traces appearing in the logs and I think a lot of specialized software has adopted the rule that indented blocks are considered part of the log line before them.
-
The gripability argument is not that strong either, because most people don't know about the
-Aand-Boptions of grep, which solves the problem to a reasonable extent. I have quite a lot of experience in grepping the indented human-readable output of https://github.com/trentm/node-bunyan (one of the most popular and established json loggers). -
The dense log produced by
textlinesdoesn't come without downsides too:- Long lines will be wrapped making them harder to read. This creates a psychological effect where the developer is incentivized to log less information in order to keep the log readable.
- Visually scanning a log line to find a particular property value will be objectively slower.
There was a problem hiding this comment.
documented these arguments as well.
I think a lot of specialized software has adopted the rule that indented blocks are considered part of the log line before them
this is an interesting point - examples of such systems? potentially, these might come from the python world where indents are the norm. I checked logstash - it has a special plugin that can deal with this by specifying a regex to match: https://www.elastic.co/guide/en/logstash/current/multiline.html - however, this is not part of the "default" config and requires extra setup
gripability argument
two things of note:
-A xx -B xx- there's no way to choose good numbers here because log lines have different numbers of params and you don't know which one you're grepping for - also, like you say, these arguments are less well known, so theout-of-the-boxexperience is worse- it's also easier to regex-match a single line - you can do
INF.*message here.*ip=XXXto get a quickandfilter.. the same holds true for IDE/editor searches etc
* throw in a test as well
|
updated to: |
easily