All Apps and Add-ons

TimeRangePicker for a dashboard

tsmithsplunk
Path Finder

I'm trying to get user entered dates or ranges to effect a dashboard that runs off a saved search. TextFields and PullDowns do not work because my saved search looks like this:

index=here sourcetype="apps_log" *Command | stats count by applog_orgName, _time | bin _time span=1d

In the PostProcess module I can't enter a "earliest" or "latest" since it just gets appended to the search and those params are invalid there.

So....maybe a TimeRangePicker will work, however, the saved search is grabbing data from -28d@d to @d. The date range needs to stay in that window or else a whole new search is run which takes quite a bit of time. The dashboard is supposed to give a quick view.

Is it possible to specify the values for the picker so they only apply to my one dashboard and not all over the app? I realize I can add custom ranges and hide standard ones, but I don't want to change the TimeRangePickers all over Splunk.

0 Karma
1 Solution

sideview
SplunkTrust
SplunkTrust

What you're asking for is possible. It's pretty weird though.

To recap, you want your users to be able to filter the results of a scheduled saved search by time. But without redispatching the search.

Secondly you have a nuance where you can't really use the TimeRangePicker because you need to exclude timeranges that dont fit inside the last 12 hours but you cant monkey with times.conf (because that would affect all timeranges in the app)

So what you do is that you use a Pulldown + ValueSetter combination to set the timerange (just like in Norbert's answer). But then you also use some shenanigans to normalize the output of that timerange to the equivalent absolute timerange, then you use that absolute timerange in a | search _time>earliest _time<latest postprocess search.

Here's how it looks. In this example I have saved a scheduled savedsearch called your_saved_search_here that runs over a 12 hour period, with the search

search = index=_internal | bin _time span="30min" | stats count by sourcetype, _time

And then this XML shows a Pulldown that allows the user to filter the results by time, but without redispatching the search. I've added some comments inline so you can understand how it works, but the best way to understand is to read the documentation and working examples for the relevant modules. You can find all that in Sideview Utils itself.

<module name="Pulldown" layoutPanel="panel_row1_col1" autoRun="True">
  <param name="staticOptions">
    <list>
      <param name="value">-1h@h,now</param>
      <param name="label">Last hour</param>
    </list>
    <list>
      <param name="value">-2h@h,now</param>
      <param name="label">Last two hours</param>
    </list>
    <list>
      <param name="value">-12h@h,-6h@h</param>
      <param name="label">Between 6 and 12 hours ago</param>
    </list>
  </param>
  <param name="name">selectedTimeRange</param>
  <param name="label">TimeRange</param>

  <!--  ValueSetter splits our Pulldown values into our two timerange pieces -->
  <module name="ValueSetter">
    <param name="delim">,</param>
    <param name="name">multivaluedKey</param>
    <param name="value">$selectedTimeRange$</param>

    <!--  This matches 0 events and returns fast but gives us a single result row -->
    <!--  with an "earliest" field and a "latest" field that are the absolute -->
    <!-- equivalent of our timerange, even if the timerange is relative -->
    <module name="Search">
      <param name="search"><![CDATA[
        foo NOT foo | stats count | addinfo | rename info_min_time as earliest info_max_time as latest
      ]]></param>
      <param name="earliest">$multivaluedKey[0]$</param>
      <param name="latest">$multivaluedKey[1]$</param>

      <!-- RVS pulls down earliest and latest and makes them into $foo$ tokens -->
      <module name="ResultsValueSetter">
        <param name="fields">earliest,latest</param>

        <module name="SavedSearch">
          <param name="name">your_saved_search_here</param>

          <!-- Finally, we just filter the savedsearch rows manually on _time -->
          <module name="PostProcess">
            <param name="search"><![CDATA[
              search _time>$earliest$ _time<$latest$
            ]]></param>

            <module name="Pager">
              <module name="Table" />
            </module>
          </module>
        </module>
      </module>
    </module>    
  </module>
</module>

If you prefer to solve this sort of thing with custom code, there is also an endpoint that the Splunk UI itself makes use of, that takes any splunk timerange string and returns the epochtime equivalent. You can see it in action if you play with the "advanced" submode of the TimeRangePicker's custom mode. From there let it "preview" for you what your argument maps to in absolute terms and you can watch the HTTP traffic. If you were also familiar with the module framework and how to use isReadyForContextPush to defer the current push, and then resume it when your little requests returned, then this could be done in a few dozen lines of custom JS. That said, the key mechanisms involved and the conventions of the isReadyForContextPush method are more or less undocumented.

The above XML, odd though it is, has the considerable advantage of involving zero custom javascript to maintain and it only using fairly simple reliable functionality in Sideview modules and in the Splunk search language.

View solution in original post

sideview
SplunkTrust
SplunkTrust

What you're asking for is possible. It's pretty weird though.

To recap, you want your users to be able to filter the results of a scheduled saved search by time. But without redispatching the search.

Secondly you have a nuance where you can't really use the TimeRangePicker because you need to exclude timeranges that dont fit inside the last 12 hours but you cant monkey with times.conf (because that would affect all timeranges in the app)

So what you do is that you use a Pulldown + ValueSetter combination to set the timerange (just like in Norbert's answer). But then you also use some shenanigans to normalize the output of that timerange to the equivalent absolute timerange, then you use that absolute timerange in a | search _time>earliest _time<latest postprocess search.

Here's how it looks. In this example I have saved a scheduled savedsearch called your_saved_search_here that runs over a 12 hour period, with the search

search = index=_internal | bin _time span="30min" | stats count by sourcetype, _time

And then this XML shows a Pulldown that allows the user to filter the results by time, but without redispatching the search. I've added some comments inline so you can understand how it works, but the best way to understand is to read the documentation and working examples for the relevant modules. You can find all that in Sideview Utils itself.

<module name="Pulldown" layoutPanel="panel_row1_col1" autoRun="True">
  <param name="staticOptions">
    <list>
      <param name="value">-1h@h,now</param>
      <param name="label">Last hour</param>
    </list>
    <list>
      <param name="value">-2h@h,now</param>
      <param name="label">Last two hours</param>
    </list>
    <list>
      <param name="value">-12h@h,-6h@h</param>
      <param name="label">Between 6 and 12 hours ago</param>
    </list>
  </param>
  <param name="name">selectedTimeRange</param>
  <param name="label">TimeRange</param>

  <!--  ValueSetter splits our Pulldown values into our two timerange pieces -->
  <module name="ValueSetter">
    <param name="delim">,</param>
    <param name="name">multivaluedKey</param>
    <param name="value">$selectedTimeRange$</param>

    <!--  This matches 0 events and returns fast but gives us a single result row -->
    <!--  with an "earliest" field and a "latest" field that are the absolute -->
    <!-- equivalent of our timerange, even if the timerange is relative -->
    <module name="Search">
      <param name="search"><![CDATA[
        foo NOT foo | stats count | addinfo | rename info_min_time as earliest info_max_time as latest
      ]]></param>
      <param name="earliest">$multivaluedKey[0]$</param>
      <param name="latest">$multivaluedKey[1]$</param>

      <!-- RVS pulls down earliest and latest and makes them into $foo$ tokens -->
      <module name="ResultsValueSetter">
        <param name="fields">earliest,latest</param>

        <module name="SavedSearch">
          <param name="name">your_saved_search_here</param>

          <!-- Finally, we just filter the savedsearch rows manually on _time -->
          <module name="PostProcess">
            <param name="search"><![CDATA[
              search _time>$earliest$ _time<$latest$
            ]]></param>

            <module name="Pager">
              <module name="Table" />
            </module>
          </module>
        </module>
      </module>
    </module>    
  </module>
</module>

If you prefer to solve this sort of thing with custom code, there is also an endpoint that the Splunk UI itself makes use of, that takes any splunk timerange string and returns the epochtime equivalent. You can see it in action if you play with the "advanced" submode of the TimeRangePicker's custom mode. From there let it "preview" for you what your argument maps to in absolute terms and you can watch the HTTP traffic. If you were also familiar with the module framework and how to use isReadyForContextPush to defer the current push, and then resume it when your little requests returned, then this could be done in a few dozen lines of custom JS. That said, the key mechanisms involved and the conventions of the isReadyForContextPush method are more or less undocumented.

The above XML, odd though it is, has the considerable advantage of involving zero custom javascript to maintain and it only using fairly simple reliable functionality in Sideview modules and in the Splunk search language.

tsmithsplunk
Path Finder

Very helpful. Thanks to both sideview and Norbert!

0 Karma

norbert_hamel
Communicator

So here is the custom time range picker build with sideview. This can be added so selected dashboards, and the required time ranges can be defined individually. My intention to build this time range picker was to remove the "Custom time", because I wanted to avoid users searching over years of data using the time range picker. And all of the default values can be hidden using the times.conf, but not the "Custom time" ...

Note that this still requires inline searches, which are fired when the time is selected, which may take some time. If you need to run a time range selection over scheduled saved searches for faster results, please get back to me.

<view onunloadCancelJobs="true" template="dashboard.html">
  <label>Custom Time Range Picker</label>

<module name="SideviewUtils" layoutPanel="appHeader"/>
<module name="AppBar" layoutPanel="appHeader"/>

<module name="Pulldown" layoutPanel="panel_row1_col1" autoRun="True">
    <param name="staticOptions">
        <list>
            <param name="value">LastThreeHours,-3h@h,now</param>
            <param name="label">Last Three Hours</param>
        </list>
        <list>
            <param name="value">Today,-0day@day,now</param>
            <param name="label">Today</param>
        </list>
        <list>
            <param name="value">Yesterday,-1day@day,-0day@day</param>
            <param name="label">Yesterday</param>
        </list>
        <list>
            <param name="value">Two days ago,-2day@day,-1day@day</param>
            <param name="label">Two days ago</param>
        </list>
        <list>
            <param name="value">Three days ago,-3day@day,-2day@day</param>
            <param name="label">Three days ago</param>
        </list>
        <list>
            <param name="value">Current week,-0week@week+1day,now</param>
            <param name="label">Current week</param>
        </list>
        <list>
            <param name="value">Last week,-1week@week+1day,-0week@week+1day</param>
            <param name="label">Last week</param>
        </list>
        <list>
            <param name="value">Two weeks ago,-2week@week+1day,-1week@week+1day</param>
            <param name="label">Two weeks ago</param>
        </list>
        <list>
            <param name="value">Three weeks ago,-3week@week+1day,-2week@week+1day</param>
            <param name="label">Three weeks ago</param>
        </list>
        <list>
            <param name="value">Current Month,-0month@month,now</param>
            <param name="label">Current Month</param>
        </list>
        <list>
            <param name="value">Last Month,-1month@month,-0month@month</param>
            <param name="label">Last Month</param>
        </list>
        <list>
            <param name="value">Two month ago,-2month@month,-1month@month</param>
            <param name="label">Two month ago</param>
        </list>
        <list>
            <param name="value">Three month ago,-3month@month,-2week@month</param>
            <param name="label">Three month ago</param>
        </list>
    </param>
    <param name="name">selectedTimeRange</param>
    <param name="label">TimeRange</param>

    <module name="ValueSetter">
        <param name="delim">,</param>
        <param name="name">multivaluedKey</param>
        <param name="value">$selectedTimeRange$</param>

        <module name="Search" layoutPanel="panel_row1_col2" autoRun="True">
            <param name="search">
                index=MyIndex earliest=$multivaluedKey[1]$ latest=$multivaluedKey[2]$ 
            </param>
        </module>

    </module>    
</module>     

</view>

tsmithsplunk
Path Finder

That could certainly be useful. Of course, I have moved on - basically I gave up on date range slices and just display the entire month of data. Thanks.

0 Karma

norbert_hamel
Communicator

I have build my own time range picker with side view, this is available only in certain dashboards. If your question is still open I could post that code snippet here over the weekend.

0 Karma
Get Updates on the Splunk Community!

Introducing Ingest Actions: Filter, Mask, Route, Repeat

WATCH NOW Ingest Actions (IA) is the best new way to easily filter, mask and route your data in Splunk® ...

Splunk Forwarders and Forced Time Based Load Balancing

Splunk customers use universal forwarders to collect and send data to Splunk. A universal forwarder can send ...

NEW! Log Views in Splunk Observability Dashboards Gives Context From a Single Page

Today, Splunk Observability releases log views, a new feature for users to add their logs data from Splunk Log ...