Getting Data In
Input methods
Pick based on control and scale: universal forwarder monitoring (best for most file and Windows event collection); network inputs such as [splunktcp://9997] for forwarded data; HTTP Event Collector (port 8088, token-based) for applications and scripts; [script://] for scheduled scripted input; [monitor://] for files and directories; and agentless options like syslog, SNMP, and database connectors. Input stanzas carry index, sourcetype, host, and must not be left at disabled = 1.
Parsing
On the parsing node, props.conf and transforms.conf handle line breaking (LINE_BREAKER, SHOULD_LINEMERGE), timestamp recognition (TIME_FORMAT, TIME_PREFIX, MAX_TIMESTAMP_LOOKAHEAD), sourcetype assignment, INDEXED_EXTRACTIONS for structured formats, and TRANSFORMS-* rules for routing, filtering, and sourcetype rewriting.
Traps
- Setting a sourcetype on the forwarder that the parsing node later overrides.
- Putting
INDEXED_EXTRACTIONSfor CSV/TSV/PSV/W3C in the wrong place - header-based extraction must be configured where the input is defined, not arbitrarily downstream. - Forgetting
disabled = 0, or being surprised when changingcrcSaltcauses re-ingestion. - Confusing the default fields source, sourcetype, and host.
Rule of thumb
Onboard a small, targeted input first and validate with the data summary or | metadata type=sourcetypes index=<idx>. If events arrive but look wrong, the problem is parsing, not transport.