All Apps and Add-ons

Changing search.timeRange.latest with Valuesetter in Sideview

david_rose
Communicator

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?

1 Solution

sideview
SplunkTrust
SplunkTrust

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>

View solution in original post

sideview
SplunkTrust
SplunkTrust

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>

david_rose
Communicator

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.

0 Karma
Get Updates on the Splunk Community!

Take Your Breath Away with Splunk Risk-Based Alerting (RBA)

WATCH NOW!The Splunk Guide to Risk-Based Alerting is here to empower your SOC like never before. Join Haylee ...

Industry Solutions for Supply Chain and OT, Amazon Use Cases, Plus More New Articles ...

Splunk Lantern is a Splunk customer success center that provides advice from Splunk experts on valuable data ...

Enterprise Security Content Update (ESCU) | New Releases

In November, the Splunk Threat Research Team had one release of new security content via the Enterprise ...