-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace zap with slog; Replace logging wrappers with slog #435
Replace zap with slog; Replace logging wrappers with slog #435
Conversation
@@ -97,11 +96,17 @@ func (r *RouteRegistry) Register(uri route.Uri, endpoint *route.Endpoint) { | |||
|
|||
switch endpointAdded { | |||
case route.ADDED: | |||
r.logger.Info("endpoint-registered", zapData(uri, endpoint)...) | |||
if r.logger.Enabled(context.Background(), slog.LevelInfo) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For completeness, we have discussed replacing this with a "flattened" group of attributes that can be evaluated lazily.
The "flattening" can be achieved in slog
by adding a "Group" attribute that has ""
as name. This is a signal to not have a group, but add all the group's elements at the same level.
While slog
does support this in its native handlers (e.g. JSONHandler
), the ZAP slog handler does not quite yet support it.
There is code in the ZAP slog handler's master branch that applies this logic, but it has not made it into a release yet.
We have taken note to improve this and remove these if
s once the ZAP slog handler supports group flattening.
c2bde8d
to
ce04e0e
Compare
00cc4c6
to
11ef228
Compare
Some of the log messages pass on complex data to be logged. When the log level is not enabled, the input data is already computed but then discarded by the logger, after checking the active log level. This check looks redundant but avoids many allocations and processing that are not needed. A nicer solution would be lazy evaluation, e.g. via callback closures, but log/slog does not support those.
… when passing nil pointers to StructValue
11ef228
to
66da390
Compare
I was able to validate the fixes for "tls-listener-started" and "tcp-listener-started". 😞 But I found another discrepancy, with the "endpoint-not-unregistered", "endpoint-registered", and "endpoint-unregistered" logs. All of them had the same capitalization discrepancy. BEFORE
AFTER
|
This is how I am doing my comparison by the way...
If the logs match it should only be the timestamp/URI/IP that are different like this...
or
|
The slog handler for Zap is configured to automatically emit stack traces at "Error" level. In pure Zap, stack traces are added via option AddStacktrace, which was not used before the move to slog. The Zap slog handler has a mapping from Zap levels to slog levels, and does not emit values above slog.LevelError. By setting the limit for automatically added stack traces via slog to ErrorLevel + 1, this effectively disables automatic stack traces. The `panic-check` handler that catches and logs panics in handlers remains unaffected, as it explicitly logs a field called "stacktrace", as it did with pure Zap. Related: #435
The slog handler for Zap is configured to automatically emit stack traces at "Error" level. In pure Zap, stack traces are added via option AddStacktrace, which was not used before the move to slog. The Zap slog handler has a mapping from Zap levels to slog levels, and does not emit values above slog.LevelError. By setting the limit for automatically added stack traces via slog to ErrorLevel + 1, this effectively disables automatic stack traces. The `panic-check` handler that catches and logs panics in handlers remains unaffected, as it explicitly logs a field called "stacktrace", as it did with pure Zap. Related: #435
The slog handler for Zap is configured to automatically emit stack traces at "Error" level. In pure Zap, stack traces are added via option AddStacktrace, which was not used before the move to slog. The Zap slog handler has a mapping from Zap levels to slog levels, and does not emit values above slog.LevelError. By setting the limit for automatically added stack traces via slog to ErrorLevel + 1, this effectively disables automatic stack traces. The `panic-check` handler that catches and logs panics in handlers remains unaffected, as it explicitly logs a field called "stacktrace", as it did with pure Zap. Related: #435
Summary
gorouter uses a very outdated
zap
version from 2016 for logging. This Pull-Request introduces required code changes to useslog
as the logging frontend, together with a zap handler viazapslog
. Slog provides a stable frontend, while we keep using zap with its configuration as the backend.Both the gorouter logger and the lager logger (used for initializing the UAA Token Fetcher) used zap logger wrappers. This Pull-Request replaces the logger wrapper with direct use of
slog.Logger
. A thin library is provided to keep it compatible with the code. The library provides the functionsCreateLogger
andCreateLoggerWithSource
to create a logger that subsequently writes data into thedata
field, and optionally sets thesource
field in the log's root. The library also has functions to dynamically set theWriteSyncer
, which is required for tests, and to dynamically set the logging level and timestamp format.With the removal of the
Logger
interface, all occurrences of the FakeLogger have been replaced with anslog.Logger
basedTestLogger
.Additionally, some test refactoring and code reformatting has been done.
Backward Compatibility
Breaking Change? No
This Pull-Request requires cloudfoundry/routing-release#434 for updating zap dependencies.
The zap handler configuration has been kept, so the log message format does not change. Workarounds for differing behavior of the
slog.Logger
frontend have been found and implemented. There are quite a lot of tests on log messages in the code, an additional end-to-end test with a deployment of this code did not show any differences compared to the old implementation.