For a particular sourcetype there are events with a timestamp and events without timestamp.
As Splunk cannot detect a timestamp in the events without timestamp, it generates plenty of errors saying 'Defaulting to timestamp of previous event'.
I am trying to clean this up.
I see that I can configure a local datetime.xml to take into account various timestamp formats.
What I would like to do is :
for event with a timestamp -> assign the correct timestamp
for events without timestamp -> assign the indexing time as the timestamp and don't throw errors
Is there a way in datetime.xml to say : for this format, apply indextime timestamp?
Thanks in advance for any hint!
Another way to solve this is to use INGEST_EVAL in transforms.conf.
LINEBREAKER = ([\r\n]+)(\d+|\w+)
SHOULDLINEMERGE = false
TIMEPREFIX = ^
TIMEFORMAT = %Y-%m-%d %H:%M:%S.%3N
MAXTIMESTAMPLOOKAHEAD = 30
TRANSFORMS = modtimestamp
INGESTEVAL = _time[float]:=if(match(raw,"^(?!\d+-\d+-\d+).*"),time(),_time)
Note: This configuration might be very impactful on the indexer's performance.
Thank both of you for your suggested solutions!
@adonio Good idea, thank you, I will test this with eval in the props.conf!
@jarizeloyola Thanks! I am using ingesteval for another source which timestamp can only be found in the filename, and it works great! However, I see splunkd timestamp errors for that source, so I have to check if ingeseval works in a way there will still have timestamp issues generated even if OK, or if it is something else!
I would suggest to use the big 6/8 of props.conf
Your props should contain these "TIMEPREFIX, TIMEFORMAT, MAXTIMESTAMPLOOKAHEAD" and
add "DATETIME_CONFIG = current".
DATETIMECONFIG is when Splunk can't find something to match TIME* .
Thanks for your answer.
Your are saying that with TIME* parameters configured and DATETIMECONFIG set to current, events with a timestamp will get timestamped according to TIME_* parameters while events from the same sourcetype without timestamp will have the indextime as the timestamp.
To my understanding setting DATETIMECONFIG to current overrides all the TIME* parameters and set the indextime as timestamp but I will test this.
would be very interesting, to know the result of your test @D2SI as i had the same understanding you had.
couple links for reference:
Alright I have tested it and it does not work, I mean if DATETIMECONFIG is set to CURRENT, it overrides any other TIME* parameter and set timestamp to indextime.
Thanks anyhow for the suggestion.
probably doesnt answer your question directly, but here is a workaround.
index all events with current timestamp
in search extract the timestamp for the field that contains time, lets say you will call it
now in search (if need to use time other then current), run something like this:
... | eval _time = if(isnull(event_time),_time,event_time) ... or something along those lines
hope it helps a little bit