Skip to content
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

Single Line Stacktraces #544

Closed
poy opened this issue Jan 26, 2018 · 3 comments
Closed

Single Line Stacktraces #544

poy opened this issue Jan 26, 2018 · 3 comments
Assignees

Comments

@poy
Copy link

poy commented Jan 26, 2018

If a stack trace is on a single line, then the loggregator system can more easily get the entire stack trace (and in proper order) to the end user. The loggregator README used to have a way to do this for java applications, but it seems more reasonable to have those docs here. The following is what used to be in the README:

Multi-line Java message workaround

Having log lines out of order can be painful when monitoring Java stack traces. There is a work around involving modifing the Java log output to have your app reformat your stacktrace messages so any newline characters are replaced by a token; and then have your log parsing code replace that token with newline characters again. The following example is for the Java Logback library and ELK, but you may be able to use the same strategy for other Java log libraries and log aggregators.

With the Java Logback library you do this by adding %replace(%xException){'\n','\u2028'}%nopex to your logging config , and then use the following logstash conf.

# Replace the unicode newline character \u2028 with \n, which Kibana will display as a new line.
    mutate {
      gsub => [ "[@message]", '\u2028', "
"]
# ^^^ Seems that passing a string with an actual newline in it is the only way to make gsub work
    }

to replace the token with a regular newline again so it displays "properly" in Kibana.

@nebhale
Copy link
Member

nebhale commented Feb 12, 2018

This is a logging framework-specific configuration and we generally don't document application-specific configurations in the Java Buildpack documentation. I'm open to being convinced that there's an obvious place for this to go, but this feels like something that is just part of application development, no matter what the platform, logging framework, or log warehousing system.

@nebhale nebhale self-assigned this Feb 12, 2018
@poy
Copy link
Author

poy commented Feb 15, 2018

I think it belongs somewhere in https://docs.cloudfoundry.org/buildpacks/java/

@nebhale
Copy link
Member

nebhale commented Feb 15, 2018

Those docs are run by a separate team and can be found here. You can open an issue or submit a PR there for changes.

@nebhale nebhale closed this as completed May 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants