Can anyone tell me the reasons why
Here is a sample event with this issue:
This event should be assigned the date: 2010-10-12 12:53:32
There are several events that were assigned this incorrect timestamp. The souretype this event is assigned to has an explicit
I looked in the original log file, and I can find "20101008135622" as a timestamp many events before the even shown in the example; But this time stamp doesn't immediately precede the example event; and the events in between this timestamp and my actual event all seem to have the correct timestamps themselves. Very odd.
Any ideas? If the time parser goes out to lunch, does that also keep the "date_*" fields from being created?
I found this issue on a new Splunk forwarder I'm in the process of setting up. I'm still testing it now, so I haven't enabled the forwarding yet; it's still running under the demo license in a local-only mode. The system is Win2k8R2 running Splunk 4.1.5.
I don't see any timestamping issues related to this in the
I've asked a new question about this: timestamp outside of the acceptable time window — Huh?
Those fields are only present when a timestamp was successfully parsed from your event. They represent the state of the parser and the literal values in the event, not an interpretation of the time in the time zone of any Splunk instance.
answered 14 Oct '10, 04:25
Stephen Sorkin ♦
I just tried this event and it should have worked find out of the box, without custom timestamping...
I don't know what your TIME_FORMAT values are, but if similar events work fine, then that's probably not the issue.
There are a few other possibly causes. Timestamps still have to pass the MAX checks, two of which could be relevant here, and default to:
if the event in question was more than 2 days in the future (somewhat unlikely) or if it was more than an hour before the previous event (possible with syslog being out of order). If your timestamps are wildly out of order, consider increasing this MAX_DIFF_SECS_AGO.
answered 11 Jan '11, 19:56