You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although the standard log system installed uses log15 key/value log lines, notably lacking is:
a reliable API for log lines
... and documentation for them
optional JSON log line formatting
The comparison might be made here to ethereumclassic/go-ethereum's mlog feature.
Specs:
Should use the pre-existing log system (which it's set up for; just add a log Handler)
Should support options for key/value and JSON formats
Should NOT write to any file; output should go to stdout (different from existing log lines which rightfully use stderr). They should use stderr because they can be considered "intended and purposeful program output" rather than incidental since turning them on requires an opt-in flag and the information they contain can be considered "program output" (as opposed to the existing logs' "incidental" nature). I'd like to have a discussion about this point and be sure to walk all the way around the reasoning here before diving in.
Should use a prefix to identify structured log lines from "normal" log lines, enabling simple grepping and piping
Should be able to provide thorough and accurate documentation for themselves (self-discovering/documenting code, eg. mdoc)
I think in general the scope of mlog is adequate, and I can't think of anything I'd prefer to leave out.
Migrated from: etclabscore/multi-geth-fork#41
Original author: @zcstarr
Although the standard log system installed uses log15 key/value log lines, notably lacking is:
a reliable API for log lines
... and documentation for them
optional JSON log line formatting
The comparison might be made here to ethereumclassic/go-ethereum's mlog feature.
Specs:
Should use the pre-existing log system (which it's set up for; just add a log Handler)
Should support options for key/value and JSON formats
Should NOT write to any file; output should go to stdout (different from existing log lines which rightfully use stderr). They should use stderr because they can be considered "intended and purposeful program output" rather than incidental since turning them on requires an opt-in flag and the information they contain can be considered "program output" (as opposed to the existing logs' "incidental" nature). I'd like to have a discussion about this point and be sure to walk all the way around the reasoning here before diving in.
Should use a prefix to identify structured log lines from "normal" log lines, enabling simple grepping and piping
Should be able to provide thorough and accurate documentation for themselves (self-discovering/documenting code, eg. mdoc)
I think in general the scope of mlog is adequate, and I can't think of anything I'd prefer to leave out.
For reference this is a repost of this issue: multi-geth/multi-geth#33
The text was updated successfully, but these errors were encountered: