Proposal: Add an "always encode numbers as strings" option to zapcore.EncoderConfig #884
Comments
fishy
added a commit
to fishy/zap
that referenced
this issue
Nov 24, 2020
This partially fixes uber-go#884. This implementation is limited to top level fields, like: Int64("int64", 123) Float64("float64", 456) Or sugared: With("int64", 123, "float64", 456) It does NOT work with reflected fields like: Reflect("array", []int{1, 2, 3}) As for reflected fields we use go's stdlib json encoder directly, which doesn't provide such feature.
fishy
added a commit
to fishy/zap
that referenced
this issue
Nov 24, 2020
This partially fixes uber-go#884. This implementation is limited to top level fields, like: Int64("int64", 123) Float64("float64", 456) Or sugared: With("int64", 123, "float64", float64(456), "slice", []int{1, 2, 3}) It does NOT work with reflected fields like: Reflect("slice", []int{1, 2, 3}) With("struct", struct{ Int64 int64 }{Int64: 123}) As for reflected fields we use go's stdlib json encoder directly, which doesn't provide such feature.
fishy
added a commit
to fishy/zap
that referenced
this issue
Nov 25, 2020
This partially fixes uber-go#884. This implementation is limited to top level fields, like: Int64("int64", 123) Float64("float64", 456) Or sugared: With("int64", 123, "float64", float64(456), "slice", []int{1, 2, 3}) It does NOT work with reflected fields like: Reflect("slice", []int{1, 2, 3}) With("struct", struct{ Int64 int64 }{Int64: 123}) As for reflected fields we use go's stdlib json encoder directly, which doesn't provide such feature.
fishy
added a commit
to reddit/zap
that referenced
this issue
Dec 3, 2020
This partially fixes uber-go#884. This implementation is limited to top level fields, like: Int64("int64", 123) Float64("float64", 456) Or sugared: With("int64", 123, "float64", float64(456), "slice", []int{1, 2, 3}) It does NOT work with reflected fields like: Reflect("slice", []int{1, 2, 3}) With("struct", struct{ Int64 int64 }{Int64: 123}) As for reflected fields we use go's stdlib json encoder directly, which doesn't provide such feature.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The reason of this proposal is that in json the only number format defined is float64. so int64 numbers in json log might lose precision from the log ingestion. Take this log line as an example:
{"level":"DEBUG","timestamp":"2020-11-24T20:50:50.393889219Z","caller":"testing/testing.go:1123","message":"test int64","int64":955216105955032459,"int64-field":955216105955032459}The log ingestion vendor we use doesn't do any special handling on json numbers, so the int64 numbers becomes
955216105955032400in their UI.The proposal is to add an option to encode them automatically into:
{"level":"DEBUG","timestamp":"2020-11-24T20:50:50.393889219Z","caller":"testing/testing.go:1123","message":"test int64","int64":"955216105955032459","int64-field":"955216105955032459"}The text was updated successfully, but these errors were encountered: