Hey all,
Cause of the Y2K bug we recently did an upgrade of our Splunk environment to version 8.0.1 - after this upgrade we do face a strange issue, which does not make any sense for us and maybe looks like a bug or something, let me explain what we have. In one of our Dashboards we do create several timestamps using the eval method, here the code:
mvindex(split($click.value$,"-"),0) strptime($STARTFROMDISPLAY$, "%d.%m.%Y %H:%M") relative_time($STARTFROMMACHINE$, "-0d@d") relative_time($STARTFROMMACHINE$, "+1d@d")
After those did run, the variables do have the following values:
- STARTFROMDISPLAY: 07.01.2020 09:52
- STARTFROMMACHINE: 1578387120 (07.01.2020 09:52)
- STARTFROMADMACHINE: 1578351600 (07.01.2020 00:00)
- ENDATADMACHINE: 1577833200 (01.01.2020 00:00)
So far so good, this is where the issue starts, if you convert these timestamps to actual dates (see above) everything is fine, except for ENDATMACHINE this is for some reason poiting to the last years end, instead to 08.01.2020 00:00 which it should and would be correct.
To make sure there is no error in the code, we did create a small and simple search (not in XML) to reproduce:
index=dhcp
| eval STARTFROMMACHINE = strptime("07.01.2020 09:52", "%d.%m.%Y %H:%M")
| eval STARTFROMADMACHINE = relative_time(STARTFROMMACHINE, "-0d@d")
| eval ENDATADMACHINE = relative_time(STARTFROMMACHINE, "+1d@d")
| table STARTFROMMACHINE, STARTFROMADMACHINE, ENDATADMACHINE
The output values of this search do look like this:
- STARTFROMMACHINE: 1578387120 (07.01.2020 09:52)
- STARTFROMADMACHINE: 1578351600 (07.01.2020 00:00)
- ENDATADMACHINE: 1578438000 (08.01.2020 00:00)
So to summarize the issue in one sentence: The **relative_time(sometimestring, "+1d@d"** does not work while using eval in the XML, but it does work if used within a search.
Does anyone have an idea what is going on here? Please let me know if you need any additional information.
Thanks.
↧