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
Get Updates on the Splunk Community!

Splunk Enterprise Security 8.x: The Essential Upgrade for Threat Detection, ...

 Prepare to elevate your security operations with the powerful upgrade to Splunk Enterprise Security 8.x! This ...

Get Early Access to AI Playbook Authoring: Apply for the Alpha Private Preview ...

Passionate about security automation? Apply now to our AI Playbook Authoring Alpha private preview ...

Reduce and Transform Your Firewall Data with Splunk Data Management

Managing high-volume firewall data has always been a challenge. Noisy events and verbose traffic logs often ...