Data Sources, Log Source Management, and Event Ingestion
Questions here focus on how events enter QRadar, how a log source is bound to a parser, and why events land as Unknown.
Core rules
- A log source combines a DSM (parser), a Log Source Identifier, a protocol, and an assigned Event Collector.
- For syslog, the identifier must match the source IP or hostname in the syslog header; a mismatch routes events to the wrong source or to Unknown.
- Common protocols: syslog 514, syslog-TLS 6514, SNMP, log file, JDBC, OPSEC, and WinCollect for Windows Event Log.
- Log Source Extensions extend parsing without editing the DSM; the DSM Editor creates custom properties and tests samples.
- Coalescing combines identical events; disabling it raises volume. Store Event Payload must stay on if regex reads the raw payload.
Worked example
Events from 10.1.1.5 show as Unknown. The collector receives them (tcpdump proves it), but no enabled log source has 10.1.1.5 as its identifier. Create a log source with that identifier, select the correct DSM and collector, enable it, deploy, then verify in Log Activity. If the DSM parses but fields are blank, test the payload in DSM Editor rather than changing the identifier.
Traps
- Confusing the log source name with its identifier.
- Assigning the log source to the wrong collector.
- Leaving a log source disabled or its DSM unlicensed.
- Coalescing away the very events a rule needs.
- Turning off payload storage and then expecting payload regex to work.