Has anyone already figure out how to deal with timestamps from windows DNS debug logs?

[gfriedmann]

I just started logging DNS debug logs from windows DNS servers. With the filename dns.log it is nicely identified as sourcetype=dns.

Timestamps are in the format 3/31/2011

Timestamp translation behaved as expected at first, but it seems that when i parsed a log file that was too far in the past (maybe +7 days?) splunk decided to reverse the order of month and year.

I kinda get why... It is just guess and has to go with it's gut. If the day is not more than 12, the month and day are ambiguous if too far in the past.

Does anyone already have knowhow and pattern to specify this format manually?

"4/8/2011 1:10:57 PM"

[sduff_splunk]

The original format didn't work for me, but I found the following expression works fine

[dns]
TIME_FORMAT=%e/%m/%Y %I:%M:%S %p

[dwaddle · Accepted solution]

Try adding a stanza to $SPLUNK_HOME/etc/system/local/props.conf containing this:

[dns]
TIME_FORMAT=%D %r

The docs cover TIME_FORMAT at http://www.splunk.com/base/Documentation/latest/Data/Configuretimestamprecognition

[gfriedmann]

I found the related problem that was causing a problem. The file i was collecting from did not update the file modified time. For some reason MAX_DAYS_HENCE=2 props.conf default setting was comparing the timestamp against the file-modified time and not the indexing time. I was expecting MAX_DAYS_HENCE= value to apply to the current indexing time and the parsed timestamp... not the file modified time vs the parsed timestamp.

[gfriedmann]

It was applied on the indexers. I still get inconsistent timestamp extractions. I am deploying universal Forwarder soon, maybe it will help with consistency.

[dwaddle]

If you are running an LWF, then this configuration needs to be applied at the indexer, not the forwarder. Where did you apply it?

[gfriedmann]

Unfortunately, it doesn't seem to be adding the correct date. Maybe i should add that these dns.log files are bing picked up by a windows light forwarder running version 4.1.6. Half of the timestamps are parsed correctly, the other half aren't.

I like your answer though. I really think it is the right answer. Maybe i have a different question i should ask.