Shared searching using a base search

To affect how many searches we kick off at one time, we can ask our panels in Splunk to refer to a base search that starts when the dashboard loads. The base search is hidden; however, the results will be displayed on the panels within the dashboard and we can still use our tokens within the search as well. You will have to go into the XML to do this, but it's often worth the performance increase.

I recommend downloading an app called Splunk 6.x Dashboard Examples. This will give you a great start; you will find some great tools to help you create some basic and even more advanced dashboards.

I will be using the preceding example app and referencing the techniques in the Recursive Search Post-process section of the Splunk 6.x Dashboard Examples.

Tip

Post-process searches are limited to 10,000 results. Anything with a timechart will almost always have more results than that.

In our previous example, all of the panels use the same data to populate their charts; however, the only panel that is not compatible with this technique is the Total Megabyes panel. Why, you ask? Because if someone sets the time range to something with more than 10,000 data points, they will come to you (the Splunk admin) and say it is broken because nothing is populating. See the preceding note.

For this example, we will focus on the bottom three panels, as they are compatible with this technique, as all three panels show only the top 10 in each:

Shared searching using a base search

If you open the Edit | show source menu, you will see the underlying XML, which will have all of the searches and tokens that you will need for this example:

   <chart> 
      <title>Top Destination IP</title> 
      <search> 
        <query>eventtype=netscaler TCP $dst_ip$  $src_ip$ | top dest_ip</query> 
      </search> 
      <option name="charting.chart">pie</option> 
    </chart> 
  <chart> 
      <title>Top Destination Port</title> 
      <search> 
        <query>eventtype=netscaler TCP $dst_ip$ $dst_port$ $src_ip$ | top dest_port</query> 
      </search> 
      <option name="charting.chart">pie</option> 
      <option name="charting.legend.placement">bottom</option> 
   </chart> 
    <chart> 
      <title>Top Source IP</title> 
      <search> 
        <query>eventtype=netscaler TCP $dst_ip$  $src_ip$ | top src_ip</query> 
      </search> 
      <option name="charting.chart">pie</option> 
      <option name="charting.legend.placement">bottom</option> 
</chart>

I have removed quite a bit of extra code due to space restrictions.

You will see that each chart begins with a <query> statement, which will be the part we need to focus on in order to adjust our searches after we create our base search.

Creating a base search

At the very top of the XML of any dashboard panel, we have the option to create a base search to reference in later panels of the dashboard.

In our case, we will create netscaler events on those references.

Following is the XML as well as the root search query we would use in order to get all of the netscaler events with a single search and to pass those results to our child panels:

<form> 
    <!-- Global search to populate everything in the panel --> 
    <search id="baseSearch"> 
        <query>eventtype=netscaler TCP | fields _time src_ip dest_ip src_port dest_port</query> 
        <earliest>-1h@h</earliest> 
        <latest>@h</latest> 
    </search>

You will notice that when we call the search module, we are also giving it an id called baseSearch.

We have structured the search in such a way that we will only see the data in the fields that we have referenced. If we were to remove the |fields _time src_ip portion of this search, then all of the fields would be present; however, the search would take slightly longer to complete. More data is equal to more time till completion.

Referencing a base search

We reference our base search in each child panel that needs to display counts or averages of any of the fields we populated in our base search.

Following is the XML that we will use to reference our base search in all of our child panels that will use this data:

<chart> 
      <title>Top Destination IP</title> 
      <search base="baseSearch"> 
        <query>search $dst_ip$  $src_ip$ | top dest_ip</query> 
      </search> 
      <option name="charting.chart">pie</option> 
  </chart> 
  <chart> 
      <title>Top Destination Port</title> 
      <search base="baseSearch"> 
        <query>search $dst_ip$ $dst_port$ $src_ip$ | top dest_port</query> 
      </search> 
      <option name="charting.chart">pie</option> 
      <option name="charting.legend.placement">bottom</option> 
   </chart> 
    <chart> 
      <title>Top Source IP</title> 
      <search base="baseSearch"> 
        <query>search $dst_ip$  $src_ip$ | top src_ip</query> 
      </search> 
      <option name="charting.chart">pie</option> 
      <option name="charting.legend.placement">bottom</option> 
</chart>

Now notice that, when we call each chart module, there is a new option called base="baseSearch". This option references the results of the search with id="baseSearch" within the dashboard.

After we have successfully referenced the results of our base search, we will then need to perform another quick search for each of our tokens so that we can filter the base result set even more when a user adds the right input.

This will effectively make the three panels in the preceding dashboard populate at the same time, as they are referencing the same data, and using this technique we have also reduced the number of concurrent searches on that single dashboard to two instead of four. This increases the amount of users that can access this dashboard at one time, while also increasing the dashboard population performance.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.110.119