Log improvements #1
Labels
enhancement
New feature or request
Milestone
Comments
dmke
added a commit
that referenced
this issue
Mar 17, 2022
- introduce go.uber.org/zap - introduce --log-level CLI flag - ensure the request ID is logged Issue: #1
|
zap is included since 9447a8d, but I don't like the formatting default console encoding: My primary issues are:
These issues can be easily addressed using either a custom |
dmke
added a commit
that referenced
this issue
Mar 17, 2022
Request ID collisions are not a concern. Issue: #1
dmke
added a commit
that referenced
this issue
Mar 17, 2022
Request ID collisions are not a concern. Issue: #1
dmke
added a commit
that referenced
this issue
Mar 17, 2022
Request ID collisions are not a concern. Issue: #1
|
Let's switch to the log/slog package for structured logging. |
|
I don't object, but need to find time to do the conversion. Fancy a PR? |
dmke
added a commit
that referenced
this issue
Jan 25, 2024
This replaces the zap logging engine with Go 1.21's new
structured logger, log/slog, or more precisely a thin
wrapper around that ("xlog").
The log/slog package has a few things missing, which are
present in xlog:
1. xlog provides a no-op logger, which simply discards any
log output. This is extensively used in our tests.
2. xlog has a Fatal() output method, which simply calls
Error() and then os.Exit(1).
3. xlog treats error values as first-class citizen. Since
(log/slog).Error() is a convenience function for their
default logger instance, there is no built-in way to treat
errors as values. In comparison, (xlog).Error() constructs
an slog.Attr, since xlog does not provide a default logger.
Point (2) is debatable, since xlog.Fatal is only used in
cmd/texd/main.go, so I'd be willing to forfeit it.
Some TODOs remain:
- xlog, i.e. its extension over log/slog, is not really tested
- documentation is missing
- the current xlog constructor (New) is a bit clunky to use,
maybe switch to functional options?
- some tests create a local buffer as log output target - this
could be made easier with a `log, buf := xlog.NewBuffered()`
constructor (albeit, the overhead is minimal)
- for local development, I still like to have some colorization
Issue: #1
dmke
added a commit
that referenced
this issue
Jan 25, 2024
This replaces the zap logging engine with Go 1.21's new
structured logger, log/slog, or more precisely a thin
wrapper around that ("xlog").
The log/slog package has a few things missing, which are
present in xlog:
1. xlog provides a no-op logger, which simply discards any
log output. This is extensively used in our tests.
2. xlog has a Fatal() output method, which simply calls
Error() and then os.Exit(1).
3. xlog treats error values as first-class citizen. Since
(log/slog).Error() is a convenience function for their
default logger instance, there is no built-in way to treat
errors as values. In comparison, (xlog).Error() constructs
an slog.Attr, since xlog does not provide a default logger.
Point (2) is debatable, since xlog.Fatal is only used in
cmd/texd/main.go, so I'd be willing to forfeit it.
Some TODOs remain:
- xlog, i.e. its extension over log/slog, is not really tested
- documentation is missing
- the current xlog constructor (New) is a bit clunky to use,
maybe switch to functional options?
- some tests create a local buffer as log output target - this
could be made easier with a `log, buf := xlog.NewBuffered()`
constructor (albeit, the overhead is minimal)
- for local development, I still like to have some colorization
Issue: #1
dmke
added a commit
that referenced
this issue
Jan 28, 2024
This replaces the zap logging engine with Go 1.21's new
structured logger, log/slog, or more precisely a thin
wrapper around that ("xlog").
The log/slog package has a few things missing, which are
present in xlog:
1. xlog provides a no-op logger, which simply discards any
log output. This is extensively used in our tests.
2. xlog has a Fatal() output method, which simply calls
Error() and then os.Exit(1).
3. xlog treats error values as first-class citizen. Since
(log/slog).Error() is a convenience function for their
default logger instance, there is no built-in way to treat
errors as values. In comparison, (xlog).Error() constructs
an slog.Attr, since xlog does not provide a default logger.
Point (2) is debatable, since xlog.Fatal is only used in
cmd/texd/main.go, so I'd be willing to forfeit it.
Some TODOs remain:
- xlog, i.e. its extension over log/slog, is not really tested
- documentation is missing
- the current xlog constructor (New) is a bit clunky to use,
maybe switch to functional options?
- some tests create a local buffer as log output target - this
could be made easier with a `log, buf := xlog.NewBuffered()`
constructor (albeit, the overhead is minimal)
- for local development, I still like to have some colorization
Issue: #1
dmke
added a commit
that referenced
this issue
Jan 28, 2024
This replaces the zap logging engine with Go 1.21's new
structured logger, log/slog, or more precisely a thin
wrapper around that ("xlog").
The log/slog package has a few things missing, which are
present in xlog:
1. xlog provides a no-op logger, which simply discards any
log output. This is extensively used in our tests.
2. xlog has a Fatal() output method, which simply calls
Error() and then os.Exit(1).
3. xlog treats error values as first-class citizen. Since
(log/slog).Error() is a convenience function for their
default logger instance, there is no built-in way to treat
errors as values. In comparison, (xlog).Error() constructs
an slog.Attr, since xlog does not provide a default logger.
Point (2) is debatable, since xlog.Fatal is only used in
cmd/texd/main.go, so I'd be willing to forfeit it.
Some TODOs remain:
- xlog, i.e. its extension over log/slog, is not really tested
- documentation is missing
- the current xlog constructor (New) is a bit clunky to use,
maybe switch to functional options?
- some tests create a local buffer as log output target - this
could be made easier with a `log, buf := xlog.NewBuffered()`
constructor (albeit, the overhead is minimal)
- for local development, I still like to have some colorization
Issue: #1
dmke
added a commit
that referenced
this issue
Oct 28, 2024
This replaces the zap logging engine with Go 1.21's structured
logger, log/slog, or more precisely a thin wrapper around that
("xlog").
The log/slog package has a few things missing, which are
present in xlog:
1. xlog provides a no-op logger, which simply discards any log output.
This is extensively used in our tests.
2. xlog has a Fatal() output method, which simply calls Error() and then
os.Exit(1).
3. xlog treats error values as first-class citizen. Since (log/slog).Error()
is a convenience function for their default logger instance, there is
no built-in way to treat errors as values. In comparison, (xlog).Error()
constructs an slog.Attr, since xlog does not provide a default logger.
Point (2) is debatable, since xlog.Fatal is only used in cmd/texd/main.go,
so I'd be willing to forfeit it.
Some TODOs remain:
- xlog, i.e. its extension over log/slog, is not really tested
- documentation is missing
- the current xlog constructor (New) is a bit clunky to use,
maybe switch to functional options?
- some tests create a local buffer as log output target - this
could be made easier with a `log, buf := xlog.NewBuffered()`
constructor (albeit, the overhead is minimal)
- for local development, I still like to have some colorization
Issue: #1
dmke
added a commit
that referenced
this issue
Oct 30, 2024
This replaces the zap logging engine with Go 1.21's structured
logger, log/slog, or more precisely a thin wrapper around that
("xlog").
The log/slog package has a few things missing, which are
present in xlog:
1. xlog provides a no-op logger, which simply discards any log output.
This is extensively used in our tests.
2. xlog has a Fatal() output method, which simply calls Error() and then
os.Exit(1).
3. xlog treats error values as first-class citizen. Since (log/slog).Error()
is a convenience function for their default logger instance, there is
no built-in way to treat errors as values. In comparison, (xlog).Error()
constructs an slog.Attr, since xlog does not provide a default logger.
Point (2) is debatable, since xlog.Fatal is only used in cmd/texd/main.go,
so I'd be willing to forfeit it.
Some TODOs remain:
- xlog, i.e. its extension over log/slog, is not really tested
- documentation is missing
- the current xlog constructor (New) is a bit clunky to use,
maybe switch to functional options?
- some tests create a local buffer as log output target - this
could be made easier with a `log, buf := xlog.NewBuffered()`
constructor (albeit, the overhead is minimal)
- for local development, I still like to have some colorization
Issue: #1
dmke
added a commit
that referenced
this issue
Oct 30, 2024
This replaces the zap logging engine with Go 1.21's structured
logger, log/slog, or more precisely a thin wrapper around that
("xlog").
The log/slog package has a few things missing, which are
present in xlog:
1. xlog provides a no-op logger, which simply discards any log output.
This is extensively used in our tests.
2. xlog has a Fatal() output method, which simply calls Error() and then
os.Exit(1).
3. xlog treats error values as first-class citizen. Since (log/slog).Error()
is a convenience function for their default logger instance, there is
no built-in way to treat errors as values. In comparison, (xlog).Error()
constructs an slog.Attr, since xlog does not provide a default logger.
Point (2) is debatable, since xlog.Fatal is only used in cmd/texd/main.go,
so I'd be willing to forfeit it.
Some TODOs remain:
- xlog, i.e. its extension over log/slog, is not really tested
- documentation is missing
- the current xlog constructor (New) is a bit clunky to use,
maybe switch to functional options?
- some tests create a local buffer as log output target - this
could be made easier with a `log, buf := xlog.NewBuffered()`
constructor (albeit, the overhead is minimal)
- for local development, I still like to have some colorization
Issue: #1
dmke
added a commit
that referenced
this issue
Oct 30, 2024
This replaces the zap logging engine with Go 1.21's structured
logger, log/slog, or more precisely a thin wrapper around that
("xlog").
The log/slog package has a few things missing, which are
present in xlog:
1. xlog provides a no-op logger, which simply discards any log output.
This is extensively used in our tests.
2. xlog has a Fatal() output method, which simply calls Error() and then
os.Exit(1).
3. xlog treats error values as first-class citizen. Since (log/slog).Error()
is a convenience function for their default logger instance, there is
no built-in way to treat errors as values. In comparison, (xlog).Error()
constructs an slog.Attr, since xlog does not provide a default logger.
Point (2) is debatable, since xlog.Fatal is only used in cmd/texd/main.go,
so I'd be willing to forfeit it.
Some TODOs remain:
- xlog, i.e. its extension over log/slog, is not really tested
- documentation is missing
- the current xlog constructor (New) is a bit clunky to use,
maybe switch to functional options?
- some tests create a local buffer as log output target - this
could be made easier with a `log, buf := xlog.NewBuffered()`
constructor (albeit, the overhead is minimal)
- for local development, I still like to have some colorization
Issue: #1
dmke
added a commit
that referenced
this issue
Oct 30, 2024
This replaces the zap logging engine with Go 1.21's structured
logger, log/slog, or more precisely a thin wrapper around that
("xlog").
The log/slog package has a few things missing, which are
present in xlog:
1. xlog provides a no-op logger, which simply discards any log output.
This is extensively used in our tests.
2. xlog has a Fatal() output method, which simply calls Error() and then
os.Exit(1).
3. xlog treats error values as first-class citizen. Since (log/slog).Error()
is a convenience function for their default logger instance, there is
no built-in way to treat errors as values. In comparison, (xlog).Error()
constructs an slog.Attr, since xlog does not provide a default logger.
Point (2) is debatable, since xlog.Fatal is only used in cmd/texd/main.go,
so I'd be willing to forfeit it.
Some TODOs remain:
- xlog, i.e. its extension over log/slog, is not really tested
- documentation is missing
- the current xlog constructor (New) is a bit clunky to use,
maybe switch to functional options?
- some tests create a local buffer as log output target - this
could be made easier with a `log, buf := xlog.NewBuffered()`
constructor (albeit, the overhead is minimal)
- for local development, I still like to have some colorization
Issue: #1
dmke
added a commit
that referenced
this issue
Oct 31, 2024
This replaces the zap logging engine with Go 1.21's structured
logger, log/slog, or more precisely a thin wrapper around that
("xlog").
The log/slog package has a few things missing, which are
present in xlog:
1. xlog provides a no-op logger, which simply discards any log output.
This is extensively used in our tests.
2. xlog has a Fatal() output method, which simply calls Error() and then
os.Exit(1).
3. xlog treats error values as first-class citizen. Since (log/slog).Error()
is a convenience function for their default logger instance, there is
no built-in way to treat errors as values. In comparison, (xlog).Error()
constructs an slog.Attr, since xlog does not provide a default logger.
Point (2) is debatable, since xlog.Fatal is only used in cmd/texd/main.go,
so I'd be willing to forfeit it.
Some TODOs remain:
- xlog, i.e. its extension over log/slog, is not really tested
- documentation is missing
- the current xlog constructor (New) is a bit clunky to use,
maybe switch to functional options?
- some tests create a local buffer as log output target - this
could be made easier with a `log, buf := xlog.NewBuffered()`
constructor (albeit, the overhead is minimal)
- for local development, I still like to have some colorization
Issue: #1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From my TODO list:
zap)X-Request-Idgenerated inservice/middleware/requestid.go--log-levelCLI flag to set log levelThe text was updated successfully, but these errors were encountered: