All turned out to be a timestamp extraction.
As soon as we removed DATETIME_CONFIG = NONE it fixed it. Go figure.
All turned out to be a timestamp extraction.
As soon as we removed DATETIME_CONFIG = NONE it fixed it. Go figure.
hmm, you should provide us some "more" details...
1. what version of Splunk you are using - free splunk or enterprise or cloud?
2. on which index you saw this above issue?
3. the SPL search query you use for this above issue?
if you are not going nuts and if you use older versions of splunk, splunk will make you go nuts automatically. (for example, the license consumption calculation has changed "drastically" on each versions of 6x, 7x, 8x, etc)
Think I just noticed part of the problem, maybe this post will still help somebody out there if they run across it (otherwise I'd delete it out of embarrassment, 😉
The data in question has a typo in the timestamp, a comma. Even though it's being extracted OK into "_time", it appears that it's enough to jack with the other "date_" extractions.
i.e.: 2022-07-20 13:07:51,352
Enterprise 8.2.6
The SPL is at it's most basic:
index=badging -- yes, it's door badging data. Yes, the timestamps are standard and are being read correctly.
I noticed that if I specify the servername the data's coming from (i.e. host=badgingserver) the fields appear (date_hour, date_minute, date_year, etc.). But those are coming from the index the server is sending it's default information to (/var/log/) -- in this case "security" before you ask. But a simple "index=badging" or a simple "index=badging host=badgingserver" -- which is a single file in /var/log/badging/badge.log -- and the fields not being there.
I wasn't aware of the index impacting whether a "default" field like date_year would appear...
Hmm, appears to be based on the index... I don't remember this being an issue -- as far as I remember, they've always been there along with _time. Anyone have any insight?