-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
New lines are escaped now #608
Comments
This is probably because we hardened the string escaping with 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:
I hope this helps. |
A switch would definitely be handy... For example LaTeX can use |
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. |
To be clear this issue is asking for an option that produces this:
^ assuming a trace that is:
|
I managed to do that approximately in this way:
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 |
We solved this with a custom formatter that looks for traces in a specific field and appends them to the log. Replace 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
} |
… separate lines sirupsen/logrus#608 indicates this is intentional, but human readable conditions often use newlines to separate output for humans. Workaround the problem for clusteroperator output. The overall error from the installer would also benefit, so those lines are tagged with TODOs.
Currently the logrus hook runs formatter once for each entry, which causes newlines to be escaped see sirupsen/logrus#608 Because of this multiline messages end up looking like ```go logrus.Info(`some message same mesage multiline 1`) logrus.Info("next meesage") ``` ``` LEVEL some message same message multiline 1 LEVEL next messsage ``` With this change the hook will format each entry's message split on newlines so that, ```go logrus.Info(`some message same mesage multiline 1`) logrus.Info("next meesage") ``` ``` LEVEL some message LEVEL same message multiline 1 LEVEL next messsage ``` This will help 2 cases, - openshift@af9b49c like informational messages that are require multiple lines to be more user-friendly. - meesages from cluster operators on install-complete failure see openshift#4242
Currently the logrus hook runs formatter once for each entry, which causes newlines to be escaped see sirupsen/logrus#608 Because of this multiline messages end up looking like ```go logrus.Info(`some message same mesage multiline 1`) logrus.Info("next meesage") ``` ``` LEVEL some message same message multiline 1 LEVEL next messsage ``` With this change the hook will format each entry's message split on newlines so that, ```go logrus.Info(`some message same mesage multiline 1`) logrus.Info("next meesage") ``` ``` LEVEL some message LEVEL same message multiline 1 LEVEL next messsage ``` This will help 2 cases, - openshift@af9b49c like informational messages that are require multiple lines to be more user-friendly. - meesages from cluster operators on install-complete failure see openshift#4242
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 logrus.SetFormatter(&logrus.TextFormatter{
ForceColors: true,
}) |
Currently the logrus hook runs formatter once for each entry, which causes newlines to be escaped see sirupsen/logrus#608 Because of this multiline messages end up looking like ```go logrus.Info(`some message same mesage multiline 1`) logrus.Info("next meesage") ``` ``` LEVEL some message same message multiline 1 LEVEL next messsage ``` With this change the hook will format each entry's message split on newlines so that, ```go logrus.Info(`some message same mesage multiline 1`) logrus.Info("next meesage") ``` ``` LEVEL some message LEVEL same message multiline 1 LEVEL next messsage ``` This will help 2 cases, - openshift@af9b49c like informational messages that are require multiple lines to be more user-friendly. - meesages from cluster operators on install-complete failure see openshift#4242
|
Terragrunt integration tests depend on newlines, and to ensure that logrus can properly print newlines with `\n` `DisableQuote: true` is needed [1]. In particular, this fixes `TestIncludeDirsDependencyConsistencyRegression` and `TestIncludeDirsStrict`. [1] - sirupsen/logrus#608
* Option for less verbose output This moves majority of Terragrunt's output to DEBUG level, and sets default output mode to ERROR. The idea is that in default run user should see much less output. Closes: #432 * Updated after review Apart from small fixes, this: - adds deprecation check for command line arguments, and gives a warning if `--terragrunt-debug` is used; - imports `logrus` under its own name to avoid confusion; Related: #432 * Updates after review | 2 Main change - global LogEntry object introduced in `util/logger.go`. It helps us log properly when we didn't yet parse command line arguments * Fix tests for `cli/cli_app.go` P.S. Tests rock! * Rework global logger Global logger should be a fallback option, rather a way to go. So instead of using the same everywhere, we use global if no other logger is available (for example, if we have not yet parsed arguments). This change also addresses other PR review comments, like: - wrong documentation; - using `logrus.WarnLevel.String()` instead of hardcoded strings; - updated `isDeprecatedOption()`, with a more clear usage; * Fix typo in docs section * Apply `go fmt` properly * Apply `go fmt` properly | 2 * Fix `TestParseTerragruntOptionsFromArgs` test * Terragrunt should output all log to stderr * Set stderr as default output * Update TestApplySkipTrue() Add `--terragrunt-log-level info`, so that we could test it. * Fix tests This fixes tests that rely on double output of `run_shell`, as well as brings back `--terragrunt-debug`, but in slightly different form: to only generate `terragrunt-debug.tfvars.json` * Remove `--terragrunt-debug` from excluded and fix `\n` Terragrunt integration tests depend on newlines, and to ensure that logrus can properly print newlines with `\n` `DisableQuote: true` is needed [1]. In particular, this fixes `TestIncludeDirsDependencyConsistencyRegression` and `TestIncludeDirsStrict`. [1] - sirupsen/logrus#608 * Bring `--terragrunt-debug` tests back
It's worked for me! Thanks |
This issue is stale because it has been open for 30 days with no activity. |
This issue was closed because it has been inactive for 14 days since being marked as stale. |
为什么不提供一个开关,比如我把日志写入日志文件中,在查看日志的时候,换行缩进显示 JSON 格式的日志将更加可读。Why not provide a switch, for example I write the log to the log file, when viewing the log, it will be more readable to display the log in JSON format with newline indentation. |
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.
The text was updated successfully, but these errors were encountered: