Splunk Search

How to pass the time of a transaction to drill down for custom search

tbrown
Path Finder

I have a panel on my dashboard that is a list of transactions. I edited the drill-down to link to the search of the transaction when I click on one of the transactions on the panel. However, the search that it links to does not show the transaction successfully because the time range is not set correctly. The search gets the beginning time of the transaction correct, but it sets the end time as only 1 second after the beginning time. How do I change this automatic 1 second interval in the search to a 2 minute interval?

This is what I have right now. Using the _time category in the transaction (attached), I've tried to extract the beginning time using the following code

 

 

<drilldown>
           <eval token="drilldown.earliest">strptime($row._time$,"%Y-%m-%dT%H:%M:%S.%3N%:z")</eval>
           <eval token="drilldown.latest">strptime($row._time$,"%Y-%m-%dT%H:%M:%S.%3N%:z") + 2m</eval>
          <link target="_blank">search?<...>;earliest=$drilldown.earliest$;latest=$drilldown.latest$</link>
        </drilldown>

 

 

But this gives the error " Invalid earliest_time.". I suspect I messed something up in the strptime command, does anyone have a fix?

Labels (4)
Tags (1)
0 Karma
1 Solution

bowesmana
SplunkTrust
SplunkTrust

@tbrown I guess this is a follow on from your other post yesterday...

 You cannot do time calculations as you are trying to do in the drilldown.latest eval statement. You will need to use relative_time function to calculate time differences.

If you are setting earliest and latest as absolute date/time strings, then they need to be in a specific format -%m/%d/%Y:%H:%M:%S

see here https://docs.splunk.com/Documentation/Splunk/8.0.5/Search/Specifytimemodifiersinyoursearch

You can actually use the raw epoch time in the earliest/latest arguments, e.g.

index=_internal earliest=1596060548.800 latest=1596060548.900

so you don't need to use any time formatting, just take the raw time value from the table. There is an issue with using a table formatted version of _time to do calculations, so this example shows how using the 't' variable to preserve the epoch, but not show it in the table, will then allow you to use relative time on the epoch.

<dashboard>
  <row>
    <panel>
      <table>
        <search>
          <query>index=_internal earliest=1596060548.800 latest=1596060548.900
| eval t=_time
| table _time t index sourcetype</query>
          <earliest>-15m</earliest>
          <latest>now</latest>
          <sampleRatio>1</sampleRatio>
        </search>
        <option name="count">20</option>
        <option name="refresh.display">progressbar</option>
        <option name="rowNumbers">false</option>
        <drilldown>
          <eval token="earliest">$row.t$</eval>
          <eval token="latest">relative_time($row.t$,"+2m")</eval>
        </drilldown>
        <fields>"_time","index","sourcetype"</fields>
      </table>
    </panel>
    <panel>
      <title>Earliest=$earliest$ latest=$latest$</title>
      <table>
        <search>
          <query>| makeresults
| eval earliest=strftime($earliest$, "%F %T.%Q")
| eval latest=strftime($latest$, "%F %T.%Q")
          </query>
          <earliest>$earliest$</earliest>
          <latest>$latest$</latest>
        </search>
        <option name="refresh.display">progressbar</option>
      </table>
    </panel>
  </row>
</dashboard>

Hope this helps.

 

View solution in original post

bowesmana
SplunkTrust
SplunkTrust

@tbrown I guess this is a follow on from your other post yesterday...

 You cannot do time calculations as you are trying to do in the drilldown.latest eval statement. You will need to use relative_time function to calculate time differences.

If you are setting earliest and latest as absolute date/time strings, then they need to be in a specific format -%m/%d/%Y:%H:%M:%S

see here https://docs.splunk.com/Documentation/Splunk/8.0.5/Search/Specifytimemodifiersinyoursearch

You can actually use the raw epoch time in the earliest/latest arguments, e.g.

index=_internal earliest=1596060548.800 latest=1596060548.900

so you don't need to use any time formatting, just take the raw time value from the table. There is an issue with using a table formatted version of _time to do calculations, so this example shows how using the 't' variable to preserve the epoch, but not show it in the table, will then allow you to use relative time on the epoch.

<dashboard>
  <row>
    <panel>
      <table>
        <search>
          <query>index=_internal earliest=1596060548.800 latest=1596060548.900
| eval t=_time
| table _time t index sourcetype</query>
          <earliest>-15m</earliest>
          <latest>now</latest>
          <sampleRatio>1</sampleRatio>
        </search>
        <option name="count">20</option>
        <option name="refresh.display">progressbar</option>
        <option name="rowNumbers">false</option>
        <drilldown>
          <eval token="earliest">$row.t$</eval>
          <eval token="latest">relative_time($row.t$,"+2m")</eval>
        </drilldown>
        <fields>"_time","index","sourcetype"</fields>
      </table>
    </panel>
    <panel>
      <title>Earliest=$earliest$ latest=$latest$</title>
      <table>
        <search>
          <query>| makeresults
| eval earliest=strftime($earliest$, "%F %T.%Q")
| eval latest=strftime($latest$, "%F %T.%Q")
          </query>
          <earliest>$earliest$</earliest>
          <latest>$latest$</latest>
        </search>
        <option name="refresh.display">progressbar</option>
      </table>
    </panel>
  </row>
</dashboard>

Hope this helps.

 

tbrown
Path Finder
 
0 Karma
Get Updates on the Splunk Community!

Announcing Scheduled Export GA for Dashboard Studio

We're excited to announce the general availability of Scheduled Export for Dashboard Studio. Starting in ...

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics GA in US-AWS!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...