(Not a timely response, but hopefully someone will find this useful). The way I handle stack traces is pretty much the same way I handle all my enterprise application parsing/indexing configurations. My approach is to configure the props.conf so that line breaks on a custom regex. Because I use a standard format I drop in some variant of the following:
MAX_EVENTS=50000
NO_BINARY_CHECK=1
SHOULD_LINEMERGE=true
MAX_TIMESTAMP_LOOKAHEAD=30
TIME_PREFIX=^\[
TRUNCATE=0
BREAK_ONLY_BEFORE=^\[\d{4}
Essentially, telling the parser, where to find the timestamp, not to ever truncate a log event and always merge until you find the start of the next header. This will pretty much take care of any multi-line log event, including a stack trace. I surround the timestamp with '[' ']' as to minimize a false match for BREAK_ONLY_BEFORE=^\[\d{4}
Since I use third party loggers like log4j/logback/log4net, which provide convenient log message pre-amble/header, I always try to standardize on:
"[%d{yyyy-MM-dd HH:mm:ss.SSS z}] [%p] [%t] [%x] [%c] %m%n"
This translates to:
"[timestamp] [log level] [thread id] [NDC] The log message"
So as long as the new line starts with "[%d{yyyy", break the event.
One concern I have with this approach is the documentation says SHOULD_LINEMERGE has a performance impact, but I dont really see any other alternatives. Hope this helps.
... View more
