DateParserVerbose - A possible timestamp match

[robgreen]

I am using splunk 4.3.1 and have a custom sourcetype

props.conf

[vlf]
REPORT-a=voxeo-vlf
TRANSFORMS-a = voxeo-vlf-index
NO_BINARY_CHECK=1
SHOULD_LINEMERGE=false
TIME_FORMAT=%Y.%m.%d.%H.%M.%S.%Q
TIME_PREFIX=\t\d+\t\d{1,2}\t
MAX_DAYS_AGO=400
DATETIME_CONFIG=NONE

transforms.conf

[voxeo-vlf]
DELIMS="\t"
FIELDS=accountid,subaccountcode,sessionid,parentsessionid,machinecode,calledid,callerid,calltype,actionid,sessionstatus,eventtime,dummy,actionnum,int2,int3,int4,string1,string2,string3,string4,sessiondata
[voxeo-vlf-index]
REGEX=^(\d+)\t
FORMAT = accountid::$1 
WRITE_META = TRUE

And get the following error messages in the log

04-13-2012 18:16:00.040 -0400 WARN  DateParserVerbose - A possible timestamp match (Sun Feb 21 08:42:06 1999) is outside of the acceptable time window. If this timestamp is correct, consider adjusting MAX_DAYS_AGO and MAX_DAYS_HENCE.
04-13-2012 18:16:00.041 -0400 WARN  DateParserVerbose - A possible timestamp match (Sun Feb 21 08:42:06 1999) is outside of the acceptable time window. If this timestamp is correct, consider adjusting MAX_DAYS_AGO and MAX_DAYS_HENCE.
04-13-2012 18:16:00.042 -0400 WARN  DateParserVerbose - A possible timestamp match (Thu Jun 27 06:35:29 2019) is outside of the acceptable time window. If this timestamp is correct, consider adjusting MAX_DAYS_AGO and MAX_DAYS_HENCE.
04-13-2012 18:16:00.042 -0400 WARN  DateParserVerbose - A possible timestamp match (Wed Sep  9 05:01:32 1998) is outside of the acceptable time window. If this timestamp is correct, consider adjusting MAX_DAYS_AGO and MAX_DAYS_HENCE.
04-13-2012 18:16:00.043 -0400 WARN  DateParserVerbose - A possible timestamp match (Wed Sep  9 05:01:32 1998) is outside of the acceptable time window. If this timestamp is correct, consider adjusting MAX_DAYS_AGO and MAX_DAYS_HENCE.
04-13-2012 18:16:00.043 -0400 WARN  DateParserVerbose - A possible timestamp match (Mon Jul 27 01:34:29 1998) is outside of the acceptable time window. If this timestamp is correct, consider adjusting MAX_DAYS_AGO and MAX_DAYS_HENCE.
04-13-2012 18:16:00.046 -0400 WARN  DateParserVerbose - A possible timestamp match (Mon Jul 27 01:34:29 1998) is outside of the acceptable time window. If this timestamp is correct, consider adjusting MAX_DAYS_AGO and MAX_DAYS_HENCE.

However i can NOT find what logs or events those log messages are talking about. Is there any debug i can turn on in log.cfg to track where it thinks its getting the date time problem from? Also, considering i have TIME_PREFIX and TIME_FORMAT can i have splunk stop trying to find the timestamp in my event since i told it exactly where it is? i tried DATETIME_CONFIG=NONE, but that imported everything with todays date.

here is an example (tab separated) log line

42623   95465   984307d59a744e15086d0dafb479b02c        host1   8001112222  4075551212  CCX 9   0   2012.04.13.18.58.59.246     0   32  0   7355882050237585344 <features></features>       0-13c4-4f88774e-8d539a74-876-1ced91b8   127.0.0.1:5060  (AppID=95465)(OutDial=)

When i get the error message the log line above it is

04-13-2012 18:15:59.711 -0400 INFO  ArchiveProcessor - reading path=/Users/rgreen/vlf/d/PopData-12978817080590142-8b31.vlf.gz (seek=164144 len=164144)

so i am assuming its complaining about data in that file, but if i do a search for source= i get back the same number of records that are in that file. Spot checking the date/time everything looks ok. Is this just a spurious error message?

thanks,
rob

[Rob]

Have you tried searching for the event by the time reported in the warning?

e.g. For the odd timestamp Thu Jun 27 06:35:29 2019
earliest="06/27/2019 06:35:29"

That way you may be able to determine the events that are getting the bad time stamp and change your props.conf accordingly

[kristian_kolb]

perhaps it's misinterpreting some numeric value for an epoch timestamp?

Try adding

MAX_TIMESTAMP_LOOKAHEAD=20

to your props.conf (for this sourcetype). Also, what is the %Q in the TIME_FORMAT? Don't think I've seen that before.

/kristian

[robgreen]

that isn't working either. It appears the data is being imported correctly and those are just spurious log entries. I have a tech support case open with splunk to confirm that.

the %Q is in "enhanced strptime() format" that splunk supports.. however i really needed %3N.. i never read the rest of the line for %N as the first sentence made it sound like it wasn't what i needed (i.e. documentation is confusing as it says nanoseconds)

%N For GNU date-time nanoseconds. Specify any sub-second parsing by providing the width: %3N = milliseconds, %6N = microseconds, %9N = nanoseconds

rob