All Apps and Add-ons

Using ValueSetter in time parameter

Wushu
Explorer

I am trying to use the ValueSetter module in-conjunction with the earliest/latest parameters. However, the new search i do must be -24hrs from the _time(time value).

Does anyone know a way of doing this?

                <module name="ValueSetter">
                    <param name="name">time</param>
                    <param name="value">$click.fields._time$</param>

        <module name="Search">
         <param name="search">index=_internal Hostname=$host$ Username=$user$ | table Hostname</param>
          <param name="earliest">$time$-2d</param>
              <param name="latest">$time$</param>

Thanks

1 Solution

sideview
SplunkTrust
SplunkTrust

Yep.

The basic idea, is that we use the Splunk search language, and the relative_time operator, to do our little piece of math where we take the clicked-upon timestamp and we turn it into the same timestamp one day before,so that we can plug it into a different search.

The key player here is the ResultsValueSetter module.

Here's the config, and then I'll walk through each step. There's a lot of places where we're using useful general stuff in Sideview Utils.

<module name="Search" layoutPanel="panel_row1_col1">
  <param name="search">* | head 10000 | stats last(_time) as _time by sourcetype</param>

  <module name="JobProgressIndicator"></module>

  <module name="Pager">

    <module name="SimpleResultsTable">
      <param name="entityName">results</param>
      <param name="drilldown">row</param>
      <param name="displayRowNumbers">False</param>

      <module name="PostProcess">
        <param name="search">| stats count | eval dayAgoTime=relative_time("$click.fields._time.epochTime$", "-1d")</param>

        <module name="ResultsValueSetter">
          <param name="fields">dayAgoTime</param>

          <module name="PostProcess">
            <param name="search"></param>

            <module name="Search">
              <param name="search">sourcetype="$click.fields.sourcetype$"</param>
              <param name="earliest">$dayAgoTime$</param>
              <param name="latest">-12h</param>

              <module name="JobProgressIndicator"></module>

              <module name="Pager">

                <module name="SimpleResultsTable">
                  <param name="entityName">results</param>
                  <param name="drilldown">row</param>
                  <param name="displayRowNumbers">False</param>
                </module>
              </module>
            </module>
          </module>
        </module>
      </module>
    </module>
  </module>
</module>

From the top it's pretty straightforward down to that first PostProcess module. Above PostProcess we just have a clickable table with some timestamps in it.

OK. That PostProcess is us being a little weird. We're using splunkd as an errand boy so that we can do our math. Since we have that existing search there, and since you can throw a "| stats count" postprocess onto any search result and wipe away what was there before, we're using the existing job only because it's slightly faster than dispatching a new one for our math problem.

You can also see PostProcess doing $foo$ substitution. the HiddenPostProcess module in core UI cannot do this.

You can also notice the $click.fields._time.epochTime$ notation. Sideview Utils patches SimpleResultsTable so that it provides more useful keys like $click.fields.sourcetype$ and $click.fields.userName$. _time is treated a bit specially by SVU, and if you want the actual epochTime value (number of seconds since 1/1/1970), you can get that with $click.fields._time.epochTime$

Next up is ResultsValueSetter. This is the module that reaches up into our newly-postprocessed search results, and pulls down our "dayAgoTime" field, making it available for all downstream modules as $dayAgoTime$.

Next up is another PostProcess module, just because postprocess doesn't automatically go away once it's used. So we have to wipe the slate clean or our funky postprocess from above will interfere with the drilldown search we're about do to down below.

OK. Now another search. See we use both the $click.fields.sourcetype$ and the $dayAgoTime$ keys in our Search module. The Sideview Search module allows $foo$ tokens to just get plugged in directly. If you were using the core HiddenSearch module you'd have to first turn these keys into "stringreplace intentions" using the ConvertToIntention module, and you'd have to plug the timerange into the search string itself instead of into the proper "earliest" argument, which would trigger some blue warnings from splunkd.

So I hope that makes sense! It's strange. There are almost no use cases of ResultsValueSetter that are not strange. It doesn't get used that often, but when it gets used, it's always "kinda crazy". works great though.

I actually built the module thinking people would use it to replace complex subsearch use cases in automated multi-step dashboards (and it's amazing if you actually do that), but so far everyone uses it for funky little tricks like this.

Big Tip: If you want to pick apart this example and see how it works, here are two ways.

1) Get the latest Sideview Utils, put this config into a view in your Splunk instance, and then use the Sideview Editor's "Runtime Debug" mode. This is a fantastic tool to peek behind the curtain at particular points in the hierarchy and watch all the $foo$ tokens stream down to it.

2) more hands on, but also useful, you can throw in HTML modules with $foo$ tokens as debugging tools. I use this trick constantly and in fact I frequently leave particularly useful ones embedded in my views, but commented out. So that I can quickly use them later when I need them. Here's an example you might use to learn more about the time tokens

 <module name="HTML">
  <param name="html"><![CDATA[
     OK so dayAgoTime right here is $dayAgoTime$<br>
     And click.fields._time.epochTime here is $click.fields._time.epochTime$<br>
     <br>
     and what's with just click.fields._time ?   $click.fields._time$<br>
     <br>
     oh.  i get it. 
  ]]></param>
</module>

View solution in original post

kurt28
Path Finder

Hello Nick, sorry to bother you. I come up against problem I didn't think it's a problem like this because I used ResultsValueSetter before and it worked.

I want to bulild a fillerGauge and set one param like this :
<param name="charting.chart.rangeValues">[0,1,2,$maxValue$]</param>

I make a simple test because I failed in my original search :

<module name="Search" autoRun="True" layoutPanel="panel_row1_col1">
    <param name="search">|stats count | eval a="-3min"</param>
    <module name="ResultsValueSetter">
      <param name="fields">a</param>
      <module name="Search">
        <param name="search">* | head 5</param>
        <param name="earliest">$a$</param>
        <param name="latest">-1min</param>
        <module name="EventsViewer"></module>
      </module>
    </module>
  </module>

In the test, svconsole indicates that the earliest time is over time range. How can I do with this?

Any help will be very appreciate.

PS: my original search :

<module name="Search" autoRun="True" layoutPanel="panel_row1_col1">
    <param name="search">sourcetype="wmi:physicalmemory" host="host1" | head 1 | eval TotalPhysicalMemory=TotalPhysicalMemory/(1024 * 1024 * 1024)</param>
    <module name="ResultsValueSetter">
      <param name="fields">TotalPhysicalMemory</param>
      <module name="Search">
        <param name="search">sourcetype="wmi:memory" host="tcsapp1" | head 1 | eval available=AvailableBytes/(1024 * 1024 * 1024) | table available</param>
        <param name="earliest">-3min</param>
        <param name="latest">now</param>
        <module name="EnablePreview">
          <param name="display">false</param>
          <param name="enable">true</param>
          <module name="HTML">
            <param name="html">
              <![CDATA[
            <h2><b><FONT color="green">host1</FONT></b></h1>
            ]]>
            </param>
          </module>
          <module name="HiddenChartFormatter">
            <param name="charting.chart">fillerGauge</param>
            <param name="charting.style">shiny</param>
            <param name="charting.chart.rangeValues">[0,1,2,$TotalPhysicalMemory$]</param>
            <param name="charting.gaugeColors">[0xBF3030,0xFFE800,0x84E900]</param>
            <module name="FlashChart"/>
          </module>
        </module>
      </module>
    </module>
  </module>
0 Karma

sideview
SplunkTrust
SplunkTrust

I think because the 'earliest' param of the Search module is not doing $foo$ substitution, that you're not using the most recent Sideview Utils app. If you're still using the version on Splunkbase, that version is very old. What's on Splunkbase is 1.3.X, but you can get the considerably newer 2.1.X version from the sideview site ( http:/sideviewapps.com/apps/sideview-utils ). In the newer version the earliest and latest params also do $foo$ substitution.

0 Karma

kurt28
Path Finder

By the way, I test your post above. It doesn't work. Is there something wrong with my dashboard?

svconsole message:
search=sourcetype="WMI:CPUTime"
timeRange.toConciseString() = over custom relative time range
timeRange.earliest = $dayAgoTime$
timeRange.latest = -12h

0 Karma

sideview
SplunkTrust
SplunkTrust

Yep.

The basic idea, is that we use the Splunk search language, and the relative_time operator, to do our little piece of math where we take the clicked-upon timestamp and we turn it into the same timestamp one day before,so that we can plug it into a different search.

The key player here is the ResultsValueSetter module.

Here's the config, and then I'll walk through each step. There's a lot of places where we're using useful general stuff in Sideview Utils.

<module name="Search" layoutPanel="panel_row1_col1">
  <param name="search">* | head 10000 | stats last(_time) as _time by sourcetype</param>

  <module name="JobProgressIndicator"></module>

  <module name="Pager">

    <module name="SimpleResultsTable">
      <param name="entityName">results</param>
      <param name="drilldown">row</param>
      <param name="displayRowNumbers">False</param>

      <module name="PostProcess">
        <param name="search">| stats count | eval dayAgoTime=relative_time("$click.fields._time.epochTime$", "-1d")</param>

        <module name="ResultsValueSetter">
          <param name="fields">dayAgoTime</param>

          <module name="PostProcess">
            <param name="search"></param>

            <module name="Search">
              <param name="search">sourcetype="$click.fields.sourcetype$"</param>
              <param name="earliest">$dayAgoTime$</param>
              <param name="latest">-12h</param>

              <module name="JobProgressIndicator"></module>

              <module name="Pager">

                <module name="SimpleResultsTable">
                  <param name="entityName">results</param>
                  <param name="drilldown">row</param>
                  <param name="displayRowNumbers">False</param>
                </module>
              </module>
            </module>
          </module>
        </module>
      </module>
    </module>
  </module>
</module>

From the top it's pretty straightforward down to that first PostProcess module. Above PostProcess we just have a clickable table with some timestamps in it.

OK. That PostProcess is us being a little weird. We're using splunkd as an errand boy so that we can do our math. Since we have that existing search there, and since you can throw a "| stats count" postprocess onto any search result and wipe away what was there before, we're using the existing job only because it's slightly faster than dispatching a new one for our math problem.

You can also see PostProcess doing $foo$ substitution. the HiddenPostProcess module in core UI cannot do this.

You can also notice the $click.fields._time.epochTime$ notation. Sideview Utils patches SimpleResultsTable so that it provides more useful keys like $click.fields.sourcetype$ and $click.fields.userName$. _time is treated a bit specially by SVU, and if you want the actual epochTime value (number of seconds since 1/1/1970), you can get that with $click.fields._time.epochTime$

Next up is ResultsValueSetter. This is the module that reaches up into our newly-postprocessed search results, and pulls down our "dayAgoTime" field, making it available for all downstream modules as $dayAgoTime$.

Next up is another PostProcess module, just because postprocess doesn't automatically go away once it's used. So we have to wipe the slate clean or our funky postprocess from above will interfere with the drilldown search we're about do to down below.

OK. Now another search. See we use both the $click.fields.sourcetype$ and the $dayAgoTime$ keys in our Search module. The Sideview Search module allows $foo$ tokens to just get plugged in directly. If you were using the core HiddenSearch module you'd have to first turn these keys into "stringreplace intentions" using the ConvertToIntention module, and you'd have to plug the timerange into the search string itself instead of into the proper "earliest" argument, which would trigger some blue warnings from splunkd.

So I hope that makes sense! It's strange. There are almost no use cases of ResultsValueSetter that are not strange. It doesn't get used that often, but when it gets used, it's always "kinda crazy". works great though.

I actually built the module thinking people would use it to replace complex subsearch use cases in automated multi-step dashboards (and it's amazing if you actually do that), but so far everyone uses it for funky little tricks like this.

Big Tip: If you want to pick apart this example and see how it works, here are two ways.

1) Get the latest Sideview Utils, put this config into a view in your Splunk instance, and then use the Sideview Editor's "Runtime Debug" mode. This is a fantastic tool to peek behind the curtain at particular points in the hierarchy and watch all the $foo$ tokens stream down to it.

2) more hands on, but also useful, you can throw in HTML modules with $foo$ tokens as debugging tools. I use this trick constantly and in fact I frequently leave particularly useful ones embedded in my views, but commented out. So that I can quickly use them later when I need them. Here's an example you might use to learn more about the time tokens

 <module name="HTML">
  <param name="html"><![CDATA[
     OK so dayAgoTime right here is $dayAgoTime$<br>
     And click.fields._time.epochTime here is $click.fields._time.epochTime$<br>
     <br>
     and what's with just click.fields._time ?   $click.fields._time$<br>
     <br>
     oh.  i get it. 
  ]]></param>
</module>

Wushu
Explorer

Thanks for the detailed answer, it is sincerely appreciated.

I got it working with your help. You sir, need more credit!

Thanks for making such a great app and giving something back. Seriously, you have made my night. Thank you.

0 Karma
Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...