I am trying to modify the search.timeRange.latest value created from a DateTime module in sideview. Specifically, I need to be able to set the timerange to be earliest=earliest and latest=earliest+24h. I assume search.timeRange.latest is the correct value I am looking for based on previous splunk answers.
When I try setting search.timeRange.latest via valuesetter, I get not keys created. If I misspell it or put it in quotes, it creates a token, but obviously is not usable in my scenario.
What am I missing? Is Valuesetter the correct module?
I looked into this and added a new testcase and you're not crazy.
DateTime does not pay attention to upstream values of the foo token $search.timeRange.earliest$, nor does it output an updated $search.timeRange.earliest$ token. This is true also for the corresponding "latest" token, and it's true whether or not the DateTime module happens to have its name set to "earliest" or "latest".
You may wonder why I'm using the phrase "$search.timeRange.label$ token" instead of just saying timerange. At the heart of the module's problematic behavior here is the fact that $search.timeRange.earliest$ is not fundamentally where the real timerange information lives, but instead it is just a $foo$ token that the Sideview modules try to always keep updated with the real time value.
And then as you might guess, the real place in the cascading context object where the timerange is kept, is unfortunately not a $foo$ token. =/
Now, plenty of other Sideview modules have gone to great length to make this convenient illusion, and DateTime absolutely should be doing so too.
Medium-to Long Term:
This behavior represents a bug. DateTime will be updated in some sensible way to pay attention to upstream tokens or to otherwise allow your use case to be reasonably implemented.
Secondly, it will output the same tokens iff its name is set to the relevant earliest/latest value.
In the meantime, there is a workaround. Well, two workarounds.
1) Use a customBehavior, ie get familiar with Sideview's customBehavior mechanism and write a bit of Javascript in application.js. This is not everyone's cup of tea. It's a simple customBehavior here and I can email it to you or update this answer with an example if you want to go this way.
2) Search Language tricks.
This is a bit unorthodox, but we can use a dummy | stats count
search to get the parent timerange and then use the search language to add on the 86,400 seconds that are in a day. Here is a working example. Yes it's bizarre. Did I mention that this option requires maintaining no code? 😃
<module name="DateTime" layoutPanel="panel_row1_col1">
<param name="label">Date</param>
<param name="name">earliest</param>
<param name="showTimepicker">False</param>
<module name="Search">
<param name="search">| stats count | addinfo | rename info_min_time as customEarliest | eval customEarliest=round(customEarliest) | eval customLatest=customEarliest + 86400</param>
<module name="ResultsValueSetter">
<param name="fields">customEarliest, customLatest</param>
<module name="Search">
<param name="search">index=_internal sourcetype=splunkd component=metrics group=per_sourcetype_thruput | head 10000 | timechart count by series</param>
<param name="earliest">$customEarliest$</param>
<param name="latest">$customLatest$</param>
<module name="HTML">
<param name="html"><![CDATA[
modified timerange is -- $search.timeRange.label$
]]></param>
</module>
<module name="JSChart"/>
</module>
</module>
</module>
</module>
I looked into this and added a new testcase and you're not crazy.
DateTime does not pay attention to upstream values of the foo token $search.timeRange.earliest$, nor does it output an updated $search.timeRange.earliest$ token. This is true also for the corresponding "latest" token, and it's true whether or not the DateTime module happens to have its name set to "earliest" or "latest".
You may wonder why I'm using the phrase "$search.timeRange.label$ token" instead of just saying timerange. At the heart of the module's problematic behavior here is the fact that $search.timeRange.earliest$ is not fundamentally where the real timerange information lives, but instead it is just a $foo$ token that the Sideview modules try to always keep updated with the real time value.
And then as you might guess, the real place in the cascading context object where the timerange is kept, is unfortunately not a $foo$ token. =/
Now, plenty of other Sideview modules have gone to great length to make this convenient illusion, and DateTime absolutely should be doing so too.
Medium-to Long Term:
This behavior represents a bug. DateTime will be updated in some sensible way to pay attention to upstream tokens or to otherwise allow your use case to be reasonably implemented.
Secondly, it will output the same tokens iff its name is set to the relevant earliest/latest value.
In the meantime, there is a workaround. Well, two workarounds.
1) Use a customBehavior, ie get familiar with Sideview's customBehavior mechanism and write a bit of Javascript in application.js. This is not everyone's cup of tea. It's a simple customBehavior here and I can email it to you or update this answer with an example if you want to go this way.
2) Search Language tricks.
This is a bit unorthodox, but we can use a dummy | stats count
search to get the parent timerange and then use the search language to add on the 86,400 seconds that are in a day. Here is a working example. Yes it's bizarre. Did I mention that this option requires maintaining no code? 😃
<module name="DateTime" layoutPanel="panel_row1_col1">
<param name="label">Date</param>
<param name="name">earliest</param>
<param name="showTimepicker">False</param>
<module name="Search">
<param name="search">| stats count | addinfo | rename info_min_time as customEarliest | eval customEarliest=round(customEarliest) | eval customLatest=customEarliest + 86400</param>
<module name="ResultsValueSetter">
<param name="fields">customEarliest, customLatest</param>
<module name="Search">
<param name="search">index=_internal sourcetype=splunkd component=metrics group=per_sourcetype_thruput | head 10000 | timechart count by series</param>
<param name="earliest">$customEarliest$</param>
<param name="latest">$customLatest$</param>
<module name="HTML">
<param name="html"><![CDATA[
modified timerange is -- $search.timeRange.label$
]]></param>
</module>
<module name="JSChart"/>
</module>
</module>
</module>
</module>
I actually ended up doing something very similar to what you suggested, doing a search to eval a new latest value from the earliest. Then using results value setter to grab the new latest value.