Drill-down - how to keep the same timeframe?

[nbcohen]

I have created a search something like this:

index="mydata" |stats count, first(supportGroup) as supportGroup by hostname | where count > 100 | stats dc(hostname) as NumHost, sum(count) as EventCount by supportGroup (Thanks to gkanapathy for helping with that!)

which produces a table like this:

SupportGroup NumHost EventCount
AAAAA 3 5000
BBBBB 10 400
CCCCC 5 1234

My question is - I have saved this search with a time frame of 'Previous Week' and that works. However, if I drill down into support group BBBB, I get a table of hosts and their event counts, but the timeframe is listed as 'custom' and approximates the previous week, but isn't exactly that time - so the event counts don't match up exactly. If I change the timeframe on the drilldown page to 'previous week' then the counts match up properly.

How do I keep the timeframe set as I drill down through the results tables? The same problem occurs at the second level - if I drill down to a single host, I get a different timeframe for the list of individual events...

Thanks,

nbc

[sideview]

Hm. Actually the reason why it switches to 'Custom' on the drilldown is so that the second search CAN be the exact same timerange as the first search. At least that's how it's supposed to work.

To take a different example, lets say your first search runs over 'Last 15 minutes'. But proper drilldown cant reuse that timerange because it's a relative timerange and the events it matches will drift over time. So instead the drilldown code gets from splunkd the absolute time range that was actually used to search the index.
When this second timerange hits the timerange, it cant be cleanly summarized in a nice concise string so the picker will put up 'Custom time'.

So here are solutions.

A) simple, but ignores root cause. Throw this downstream from your first click (be it a table or chart), and below any ConvertToDrilldownSearch module for good measure.

<module name="HiddenSearch">
  <param name="earliest">-1w@w0</param> 
  <param name="latest">-1w@w0</param>

  [[ your ViewRedirector or your second table/chart or what-have-you ]]

</module>

That will obliterate the timerange set. Note that if the first search is run on Saturday at 11:59PM and the click happens at Sunday 12:01AM, the drilldown will be wildly different. 😃

B) investigate the root cause. Can you post what exactly the timerange is of the second search? Because it should really be the exact same absolute time argument that splunk used, and therefore it should really match the exact same events. there should be no mismatch at all between counts. Certainly not for a timerange as stable and dependable as 'Previous Week'

One easy way to manually debug the timerange, or downward travelling data in general, is to stitch one or more of these into your view (at the level of an existing module rendering results)

<module name="SimpleResultsHeader">
  <param name="headerFormat">$time$</param> 
  <param name="entityName">results</param>    
</module>

other keys you can print out : $search$ will print the search string, $click.name$, $click.value$ can print your table drilldown values from upstream, and you can print out lister keys as well. It can be a very useful sanity check.

[nbcohen]

Nick - I understand what you are saying, but I'm too new to Splunk to know how (or where) to put those code snippets - I'll look into that. Meanwhile, the original time was 'Previous Week'. Drill gives custom time: from 5:00:00 AM November 14 to 5:00:00 AM November 21, 2010 and the event count does not match the original row of my table. It's close... I'll dig deeper - thanks - nbc