C:\Program Files\Splunk\etc\system\local\props.conf contains
[YYY] TIME_PREFIX = timestamp= SHOULD_LINEMERGE = false LINE_BREAKER = ([\r\n]+)<log4j:event
The 6.1.2 docs indicate "If the TIME_PREFIX cannot be found in the event text, timestamp extraction does not take place."
A broken incoming raw event:
DELETE FROM TABLE1 WHERE modified_date < TO_DATE('2014-07-21 17:59:59', 'YYYY-MM-DD HH24:MI:SS') Deleted 0 rows in (ms) 16 ]]></log4j:message> </log4j:event>
Splunk appears to extract the slightly (by a couple of hours) future timestamp "2014-07-21 17:59:59" from the raw event (which is actually a SQL parameter) and uses that as the timestamp of the current event, instead of the current timestamp.
Is this a bug?
Looks like the forwarder's sourcetype configs under
C:\Program Files\SplunkUniversalForwarder\etc\apps\learned\local\
had somehow "learned" an incorrect sourcetype definition for YYY that was correctly defined on the indexer.
Fixing those forwarder configs solved the broken event problem.
Looks like the forwarder's sourcetype configs under
C:\Program Files\SplunkUniversalForwarder\etc\apps\learned\local\
had somehow "learned" an incorrect sourcetype definition for YYY that was correctly defined on the indexer.
Fixing those forwarder configs solved the broken event problem.