Panel-defined search driven by select dropdown

[blurblebot]

I'm clobbering myself trying to understand exactly which mechanism in this xml sample from the UI example, "panel-defined search driven by select dropdown" is declaring that the dropdown be populated with available sourcetypes. With the modules and params named as they are, I don't know which are good labeling, and which is the critical nugget that tell splunk to use sourcetype.

Can anyone help me out, please?

  <module name="SearchSelectLister" layoutPanel="viewHeader">
    <param name="staticFieldsToDisplay"/>
    <param name="search">index=_internal source=*metrics.log group="per_sourcetype_thruput" | chart count over series</param>
    <param name="label">butterchurn</param>
    <param name="settingToCreate">sourcetype_setting</param>
    <param name="searchFieldsToDisplay">
      <list>
        <param name="value">series</param>
        <param name="label">series</param>
      </list>
    </param>
    <param name="searchWhenChanged">False</param>
    <param name="earliest">-60m</param>
    <module name="ConvertToIntention">
      <param name="settingToConvert">sourcetype_setting</param>
      <param name="intention">
        <param name="name">stringreplace</param>
        <param name="arg">
          <param name="sourcetype">
            <param name="fillOnEmpty">True</param>
            <param name="suffix">*</param>
            <param name="value">$target$</param>
          </param>
        </param>
      </param>
      <module name="TimeRangePicker">
        <param name="searchWhenChanged">False</param>
        <module name="SubmitButton">
          <param name="allowSoftSubmit">True</param>
          <param name="label">Search</param>
          <module name="StaticContentSample" layoutPanel="panel_row1_col1">
            <param name="text">&lt;h1&gt;Multi-panel linked form search&lt;/h1&gt;&lt;p&gt;This form search will dispatch 4 seperate searches, each listening
          to the common 'sourcetype' text box input.  This is useful for rendering
          pages that collate disparate searches that share a common search keyword/token.
        &lt;/p&gt;&lt;p&gt;
          This form search is nearly identical to &lt;a href="form4"&gt;Form search 4 - inverted flow, panel-defined post-process&lt;/a&gt;.
        &lt;/p&gt;&lt;p&gt;NOTE: because this page dispatches multiple searches, the JobStatus bar
          does not appear.
        &lt;/p&gt;</param>
          </module>
          <module name="HiddenSearch" layoutPanel="panel_row2_col1" group="KB Indexed over time" autoRun="False">
            <param name="search">index=_internal source=*metrics.log group="per_sourcetype_thruput" series="$sourcetype$" | timechart sum(kb)</param>
            <param name="groupLabel">KB Indexed over time</param>
            <module name="ViewstateAdapter">
              <module name="HiddenFieldPicker">
                <param name="strictMode">True</param>
                <module name="JobProgressIndicator">
                  <module name="EnablePreview">
                    <param name="enable">True</param>
                    <param name="display">False</param>
                    <module name="HiddenChartFormatter">
                      <param name="charting.chart">area</param>
                      <module name="FlashChart">
                        <param name="width">100%</param>
                        <module name="ConvertToDrilldownSearch">
                          <module name="ViewRedirector">
                            <param name="viewTarget">flashtimeline</param>
                          </module>
                        </module>
                      </module>
                      <module name="ViewRedirectorLink">
                        <param name="viewTarget">flashtimeline</param>
                      </module>
                    </module>
                  </module>
                </module>
              </module>
            </module>
          </module>

Thanks!

-s

[sideview · Accepted solution]

This example is extremely convoluted because this is one of the Simplified XML examples, that was then converted into Advanced XML. The conversion process makes some strange choices sometimes.

And the title probably makes more sense when it's the simplified XML, because the pulldown element has a populatingSearch param that's more front-and-center.

But anyway, to answer your question it's the search param of the first SearchSelectLister module.

whose value is:

index=_internal source=*metrics.log group="per_sourcetype_thruput" | chart count over series

It's just an example and definitely an unfortunate one. A MUCH faster search to get the list of available sourcetypes is simply | metadata type=sourcetypes. I've seen people copy and paste this example out into production code and getting the sourcetypes from the metrics log like this is 100 or more like 10,000 times slower than getting them from the metadata command.

However, to explain why that search does technically work, in the metrics log, in group="per_sourcetype_thruput", each value of the field series is a sourcetype. However the metrics log does NOT report every sourcetype necessarily only the loudest, so really quiet sourcetypes can fly completely under the radar of such a search.

a more compact version of the first two modules, with the search swapped out, is as follows:

<module name="SearchSelectLister" layoutPanel="viewHeader">
    <param name="search">| metadata type=sourcetypes</param>
    <param name="label">butterchurn</param>
    <param name="settingToCreate">sourcetype</param>
    <param name="searchFieldsToDisplay">
      <list>
        <param name="value">sourcetype</param>
        <param name="label">sourcetype</param>
      </list>
    </param>
    <module name="ConvertToIntention">
      <param name="intention">
        <param name="name">stringreplace</param>
        <param name="arg">
          <param name="sourcetype">
            <param name="fillOnEmpty">True</param>
            <param name="suffix">*</param>
            <param name="value">$sourcetype$</param>
          </param>
        </param>
      </param>

And I changed the searchWhenChanged param to True because the usability is much better this way. searchWhenChanged should never (or at least almost never) be set to False.

(and if/when you need what it does, it's a much better idea to have a SubmitButton downstream with allowSoftSubmit set to False instead).

You should have better luck with the Advanced XML examples in the UI_Examples app, rather than this one which is just a simplified XML example that was at some point converted to advanced XML.

[blurblebot]

Fantastic answer. Thank you.