Getting Data In

Incorrect Timestamp

hlarimer
Communicator

I have the following log and need splunk to grab the second timestamp instead of the first. I have tried adjusting props.conf as shown below as well.

Task Update Application Available Targeting is due at Wednesday 03/09/2016 00:00:00  $$<SMS_DATABASE_NOTIFICATION_MONITOR><03-08-2016 19:00:26.917+00><thread=6760 (0x1A68)>

Props.conf

[server_log]
TIME_PREFIX = ><
TIME_FORMAT = %m-%d-%y %H:%M:%S.
Tags (1)
0 Karma
1 Solution

martin_mueller
SplunkTrust
SplunkTrust

Your TIME_FORMAT should be %m-%d-%Y %H:%M:%S.%3N, possibly plus timezone info if the +00 refers to UTC.
After setting that, make sure you restart Splunk and only look at newly indexed events - existing ones won't change.

View solution in original post

martin_mueller
SplunkTrust
SplunkTrust

Your TIME_FORMAT should be %m-%d-%Y %H:%M:%S.%3N, possibly plus timezone info if the +00 refers to UTC.
After setting that, make sure you restart Splunk and only look at newly indexed events - existing ones won't change.

View solution in original post

hlarimer
Communicator

Thanks Martin, I added those changes but I'm still getting the first timestamp instead of the second. I added the changes last night and then restarted the splunk forwarder. Do you think the TIME_PREFIX is correctly?

0 Karma

martin_mueller
SplunkTrust
SplunkTrust

Setting those two things works for me:

alt text

0 Karma

hlarimer
Communicator

Maybe I have this set in the incorrect place then, I have it in props.conf on the UF, should it actually be on the SH?

0 Karma

martin_mueller
SplunkTrust
SplunkTrust

It should be on the instance that performs the parsing: http://wiki.splunk.com/Community:HowIndexingWorks

Usually that's the indexers, sometimes heavy forwarders, only very rarely (e.g. INDEXED_EXTRACTIONS) universal forwarders, also rarely search heads (e.g. combined search head with DB Connect, modular inputs, etc).

hlarimer
Communicator

Thanks Martin, it looks like moving it to indexers took care of it! That was my mistake, I was thinking that timestamp extraction happened earlier.

0 Karma

martin_mueller
SplunkTrust
SplunkTrust

Great - don't forget to mark the answer as accepted.

0 Karma