props.conf

# Use *one* of the below entries in local/props.conf on your Splunk Heavy Forwarder or Indexer
# See also:  https://docs.splunk.com/Documentation/Splunk/8.2.6/Admin/Propsconf


# NOTE: It is STRONGLY suggested that you do not change TRUNCATE to a value other than 0.
# Truncated records lead to invalid JSON and missing data.
# If you want to truncate excessively long text fields, use the output.truncate setting
# in your scannername.properties files (see example-config.properties), which will truncate
# only offending fields, keeping the validity of the JSON intact, rather than truncating
# the entire JSON record


# OPTION #1 -- This props.conf entry should suffice in most cases, if you are not
# ingesting historical data that is more than ~5 years old

[tenapull]
TRUNCATE = 0
LINE_BREAKER=([\r\n]+)
SHOULD_LINEMERGE=false
NO_BINARY_CHECK=true
CHARSET=AUTO
KV_MODE=json
TIME_PREFIX=^\{\"scan_timestamp\"\:\"
TIME_FORMAT=%Y-%m-%d %H:%M:%S
MAX_TIMESTAMP_LOOKAHEAD = 20



# OPTION #2 -- If the timestamps for old historical records are being given current timestamps,
# then you may need to use a transform at ingest time to override Splunk's timestamp filters,
# using the below configuration.
#
# NOTE: Before trying this, it would be prudent to confirm that more recent timestamps
# (e.g. a month or two old) are being correctly ingested.  If not, then it is likely an
# issue with how the timestamps are being parsed, rather than the age of the timestamps
# that is causing the problem.  OPTION #2 should solve the latter problem (age of timestamp)
# but is not intended to solve a parsing problem.

[tenapull]
TRUNCATE = 0
LINE_BREAKER=([\r\n]+)
SHOULD_LINEMERGE=false
NO_BINARY_CHECK=true
CHARSET=AUTO
KV_MODE=json
DATETIME_CONFIG=NONE
TRANSFORMS=tenapull_timestamp_eval


# IMPORTANT: For OPTION #2, you will also need to include the following in a
# local/transforms.conf file (NOT in props.conf!)

[tenapull_timestamp_eval]
INGEST_EVAL = _time=strptime(substr(_raw,20,19),"%Y-%m-%d %H:%M:%S")


# If you tried OPTION #2 and are still running into timestamp issues for historical records,
# it is also possible to configure the output.timestamp.floor setting in your scannername.properties
# file, which will create a floor for the timestamps which Splunk reads, at the date/time that you
# specify.  See example-config.properties for more information