Most bad data in Splunk is not a Splunk problem. It is a parsing problem, and it traces back to a source type that went into production without the settings that control how Splunk breaks, timestamps, and truncates events. Get those wrong and you pay for it three ways: wasted license volume on line-merged junk, searches that miss events because the timestamp landed in the wrong day, and dashboards that quietly undercount.

There is a short list of props.conf attributes that fixes almost all of it. Splunk practitioners call it the "Great Eight." Set these every time you onboard a new source type, before it ever reaches a production index.

Why these eight

Splunk applies index-time settings once, when the event is written. If the source type is wrong, re-indexing is the only real fix, and in a regulated environment that means a change record and a maintenance window. The Great Eight covers the three things Splunk has to get right at index time: where one event ends and the next begins, what time the event happened, and how much of the event to keep.

The settings

1. LINE_BREAKER. Anchor it to the pattern that starts a new event, not the default newline. This is the single most important setting for multi-line data. A regex that captures the boundary in a capturing group tells Splunk exactly where to cut.

2. SHOULD_LINEMERGE = false. Turn off line merging. With LINE_BREAKER doing the work, line merging is slow, unpredictable, and usually wrong. False is the default you want for almost every modern source type.

3. TRUNCATE. Set it to your maximum expected event length plus roughly ten percent. Never leave it at 0, which disables truncation and lets a single runaway event balloon your ingest. Never leave it at the 10,000-byte default if your events run longer, because Splunk will silently cut them.

4. EVENT_BREAKER_ENABLE = true and EVENT_BREAKER. On universal forwarders 6.5 and later, these let the forwarder break events before they reach the indexer, which keeps distribution even across your indexers. Match EVENT_BREAKER to your LINE_BREAKER pattern.

5. TIME_PREFIX. Anchor Splunk to the start of the timestamp with a regex. Without it, Splunk guesses, and guessing is how you end up with events dated 1970 or filed under the wrong day.

6. MAX_TIMESTAMP_LOOKAHEAD. Set it to the exact character length of your timestamp. This stops Splunk from scanning further into the event and grabbing a number that looks like a date but is not.

7. TIME_FORMAT. Specify the timestamp format explicitly using strptime syntax. Explicit beats inferred every time, especially for formats Splunk handles ambiguously, like day-first dates.

8. CHARSET and ANNOTATE_PUNCT (the optional two). Set CHARSET when your data is not UTF-8. Set ANNOTATE_PUNCT = false to save indexing overhead you almost never use. These round out the list.

Name it right and ship it right

The settings only help if they land in the right place. Name the source type vendor:product:technology:format so it is self-documenting and plays well with the Common Information Model. Prefer a Splunk-certified or CIM-compliant add-on when one exists, so field extractions and CIM mapping come for free. Deploy the configuration in a custom app, never in system/local, so it survives upgrades and stays under version control.

Where this fits

Source typing is stage three of a larger workflow. For the full picture, from intake through hand-off, see Data onboarding without the rework. And if you operate under NERC CIP, clean onboarding is not just hygiene, it is evidence: Onboarding data under NERC CIP. Reach out for our one-page Data Onboarding Checklist.