When a log event results in a multi-line output, papertrails will receive them as one line with correct source and application, and the following lines without correct hostname.
This results in output looking like this:
Jan 23 16:04:56 193.213.209.1 advisoradmin-server: INFO o.h.jpa.internal.util.LogHelper: HHH000204: Processing PersistenceUnitInfo [
Jan 23 16:04:56 193.213.209.1 logger: name: default
Jan 23 16:04:56 193.213.209.1 logger: ...]
This occurs due to papertrails not handling the newlines as part of the same message. In practice this means that filtering on hostname filters out the corresponding lines from the log(!)
If, instead, we send the lines separately when logging on different lines, the lines will all contain the hostname.
With this patch, the resulting output looks like this:
Jan 23 16:17:01 193.213.209.1 advisoradmin-server: INFO o.h.jpa.internal.util.LogHelper: HHH000204: Processing PersistenceUnitInfo [
Jan 23 16:17:01 193.213.209.1 advisoradmin-server: name: default
Jan 23 16:17:01 193.213.209.1 advisoradmin-server: ...]
The downside, obviously, is more traffic when logging multi-line log lines.
When a log event results in a multi-line output, papertrails will receive them as one line with correct source and application, and the following lines without correct hostname.
This results in output looking like this:
This occurs due to papertrails not handling the newlines as part of the same message. In practice this means that filtering on hostname filters out the corresponding lines from the log(!)
If, instead, we send the lines separately when logging on different lines, the lines will all contain the hostname. With this patch, the resulting output looks like this:
The downside, obviously, is more traffic when logging multi-line log lines.