Hi!
With a recent update I've noticed that my debug data dumps in logs get fully escaped. Previously, I had _nicely formatted_ data structs in output (using spew.Sdump), so I could actually read them.
Code:
log.Debug(spew.Sdump(data))And now I get:
(*pkg.Data)(0xc423e8cb00)({\n UUID: (string) \"\",\n Property:...
I've browsed through recent updates, but can't find a way to turn this off other then fixing version of logrus to some previous one. Please advise. The data dumps are unreadable now.
This is probably because we hardened the string escaping with %q instead of the previous unsafe escaping.
See #580
I'm afraid there isn't much we can do here. This could actually be considered as a bug which has been fixed. Being able to send new lines in your log could make them harder to read, and actually reduce the purpose of structured logging, where you would only log specific meaningful fields not dump a whole json object.
This makes sense when logging in production with an elk stack that parses the message, but when logging for development this is really annoying. Stack traces that are logged are now unreadable. If logged to TTY could this change be undone (just like we have colouring in this case? Or maybe make it configurable, because sometimes when logging to a file for development you also want the previous behaviour.
Yes please on this one. Having a switch of some sort would be very nice.
Another use case I have where I am printing json serialized objects in the debug logs. In the printed json, all double quotes are escaped too making it totally unreadable.
we have run into the need to print the stack traces in our logs as well and the removal of the new lines on stdout makes them very hard to read, is this going to be considered?
For human consumption, I am using https://github.com/antonfisher/nested-logrus-formatter which does not escape the text content.
For example:
Mar 18 09:32:26.740 [INFO] [Content:## Generated by my-tool
# Read the policy
path "sys/policies/acl/a-policy" {
"capabilities" = [ "read" ]
}
path "secret/*" {
"capabilities" = ["read","list"]
}
path "auth/token/create/a-role" {
"capabilities" = ["update"]
"denied_parameters" = {"*"=[]}
}
] [Environment:dev]
I hope this helps.
A switch would definitely be handy...
For example LaTeX can use \n as a start of custom command very often which makes it quite hard to convert these escaped new lines back to, you know, just new lines. And debugging dynamically generated LaTeX templates without being able to actually look at the generated template is, you know, just sad.
Another vote for being able to decide whether the log should escape or not-escape newlines. Come on, this is common sense.
Why logrus keep line number and new line escape so unconvenient? This is golang way?
Vote for an option to decide if newline should be escaped in log.
Newline is really more readable when log stack trace.
To be clear this issue is asking for an option that produces this:
time="2009-11-10T23:00:00Z" level=info traceField=line 1
line 2
line 3 otherLogField=bar
^ assuming a trace that is:
line 1
line 2
line 3
I managed to do that approximately in this way:
if log.GetLevel()==log.DebugLevel {
strSlice:=strings.Split(str, "\n")
for _, s := range strSlice {
log.Debug(s)
}
}
It's not ideal solution but at least it works somehow... Also it will be called only in development when you set level to DebugLevel. I think there is no need to use debug messages in production. So no need to use multiline output in production. Hope, this code helps someone;)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Need ability to enable or disable such behavior and ability to configure striping/replacing new lines in message fields.
reasonale to enable newline...
For all kinds of local testing, this option would be extremely useful.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Re-pinging on this to prevent it from getting closed. Right now, the only option that I can tell is fmt.Fprintf(logrus.StandardLogger().Out, theStr)
We solved this with a custom formatter that looks for traces in a specific field and appends them to the log. Replace stack with your field of choice.
func TestMain(m *testing.M) {
testLogger.SetLevel(logrus.WarnLevel)
testLogger.SetFormatter(&StackFormatter{})
os.Exit(m.Run())
}
type StackFormatter struct {
logrus.TextFormatter
}
// Render a log entry with a TextFormatter - except if there is a `stack` field, print it (with newlines) after the log message.
func (f *StackFormatter) Format(entry *logrus.Entry) ([]byte, error) {
stack, ok := entry.Data["stack"]
if ok {
delete(entry.Data, "stack")
}
res, err := f.TextFormatter.Format(entry)
if stack, ok := stack.(string); ok && stack != "" {
res = append(res, []byte("stack trace:\n"+stack)...)
}
return res, err
}
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
It is not stale!
same to me .ä¿ºä¹Ÿä¸€æ ·
I set ForceColors true to resolve this problem, BUT I don't know why
logrus.SetFormatter(&logrus.TextFormatter{
ForceColors: true,
})
logger.SetFormatter(&logrus.TextFormatter{
DisableQuote: true,
})
https://github.com/sirupsen/logrus/pull/1134/commits/c7455de10af6bbe2b2bdafee2cb682e813817ed2
logger.SetFormatter(&logrus.TextFormatter{ DisableQuote: true, })
It's worked for me! Thanks
Most helpful comment
This makes sense when logging in production with an elk stack that parses the message, but when logging for development this is really annoying. Stack traces that are logged are now unreadable. If logged to TTY could this change be undone (just like we have colouring in this case? Or maybe make it configurable, because sometimes when logging to a file for development you also want the previous behaviour.