Getting Data In

Can the "exception" log record that looks different from the regular log records and is spanned across a bunch of lines be indexed as one Splunk event? The whole log goes to the same sourcetype.

yg
Explorer

Can the "exception" log record that looks different from the regular log records and is spanned across a bunch of lines be indexed as one Splunk event? The whole log goes to the same sourcetype.

To split the events I used in props.conf
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)

Although all the regular info-level log records have the timestamps, without this configuration some log records would be merged together into the same Splunk event probably because of the very high data density coming from this log.

Here is the issue:
Sometimes the log would have an "exception" record spanned across multiple lines with the lines number 2 and after not having the timestamp in them but they mostly would start with "\sat\s" pattern. It would look like this:
<info-level record>
<the start of the exception record>
<tab>at ...
<tab>at ...
<tab>at ...
<tab>at ...
<info-level record>
<info-level record>

I added
MUST_NOT_BREAK_BEFORE = \sat\s
to the sourcetype stanza but it didn't help and the exception was broken into multiple Splunk events after the indexing.

Is there a way to keep the exception as one Splunk event without affecting the regular info-level log records?

Thank you.

0 Karma
1 Solution

martin_mueller
SplunkTrust
SplunkTrust

Amend your LINE_BREAKER to look for a timestamp-y part after the carriage-return/newline. That way it'll only break if there's actually a next event following, not if a multi-line event is present.

MUST_NOT_BREAK_BEFORE is useless here because it affects the aggregator / line merger. You've correctly turned that off because you're using the more efficient LINE_BREAKER.

View solution in original post

martin_mueller
SplunkTrust
SplunkTrust

Amend your LINE_BREAKER to look for a timestamp-y part after the carriage-return/newline. That way it'll only break if there's actually a next event following, not if a multi-line event is present.

MUST_NOT_BREAK_BEFORE is useless here because it affects the aggregator / line merger. You've correctly turned that off because you're using the more efficient LINE_BREAKER.

yg
Explorer

Thank you! It did work. This configuration removed the time from the beginning of the Splunk events but there are system timestamps (_time).

0 Karma
*NEW* Splunk Love Promo!
Snag a $25 Visa Gift Card for Giving Your Review!

It's another Splunk Love Special! For a limited time, you can review one of our select Splunk products through Gartner Peer Insights and receive a $25 Visa gift card!

Review:





Or Learn More in Our Blog >>