Dashboards & Visualizations

How to update FieldPicker for a SimpleResultsTable in a HiddenPostProcess Search

Splunk Employee
Splunk Employee

I've reviewed some of the HiddenPostProcess literature previously made available on this site regarding intentions for a separate FieldSearch question.

This is about FieldPicker though. I have a single HiddenSearch Search upstream from many HiddenPostProcess Searches which populate a veritable cornucopia of SimpleResultsTables.

Is it possible for each SimpleResultsTable to have its own FieldPicker - and populate the list of that FieldPicker with only fields that make sense for its SimpleResultsTable.

I am able to do this with multiple HiddenSearch Searches (one specially crafted for each SimpleResultsTable) but not using a HiddenPostProcess Search.

Are there any methods available to use a HiddenPostProcess Search to update a Field Picker?

<module name="HiddenPostProcess" layoutPanel="panel_row3_col1">
  <param name="search">`_dashboard_x_y-matched`</param>
  <module name="Count">
    <param name="options">
      <list>
        <param name="text">10</param>
        <param name="value">10</param>
      </list>
      <list>
        <param name="text">20</param>
        <param name="selected">True</param>
        <param name="value">20</param>
      </list>
      <list>
        <param name="text">50</param>
        <param name="value">50</param>
      </list>
      <list>
        <param name="text">100</param>
        <param name="value">100</param>
      </list>
    </param>
    <module name="FieldPicker">
      <param name="fields">user_id, field_a, field_b</param>
      <module name="SimpleResultsTable" group="Y Matched">
         <param name="entityName">results</param>
         <param name="drilldown">all</param>
         <param name="allowTransformedFieldSelect">True</param>
Tags (1)
1 Solution

SplunkTrust
SplunkTrust

OK. it's a bit of a journey, but here goes.

The FieldPicker module cannot show the fields from a postprocess'ed set of results.

FieldPicker and it's modal popup layer will in all cases just show the fields and breakdowns and top values of the underlying events, the un-postprocess'ed rows.

So to take a trivial example, if none of your postProcess searches actually transform the rows, or add any fields or remove any fields, then it would actually work. But this is an extremely unlikely scenario.

Another example: if a postProcess search transforms the rows, like turns events into a set of rows where each row is a distinct 'user', and you want the FieldPicker to show the fields that are available for the user rows, you're out of luck. FieldPicker will keep showing the fields from the raw events, and it wont show you any of the correct fields.

Another example: if the postProcess search adds or removes a field, the FieldPicker will not show the new field in the first case, and keep showing the unwanted field in the second.

The only glimmer of good news, is that the final output of the FieldPicker module, the only thing it tells the SimpleResultsTable, is a key called "results.fields". So in theory you could have a StaticSelect module (or in sideview_utils a Pulldown module), where each <option> is a combination of fields. This is clunky but might suit your needs if you can boil it down to a couple combinations.

If you're using the Pulldown module from the sideview_utils app, it has a multiple selection mode and in that case you could make it be a simple FieldPicker, where each <option> is a separate field. You can have this list configured statically or you can have it itself come from a postProcess search (. At the end of the day it would output "results.fields" and it would act as a simple little fieldPicker. it of course has no modal popup functionality nor summary statistics nor top 10 values nor much of anything fancy. But ctrl-clicking fields there would indeed effect the SimpleResultsTable downstream. sideview_utils docs has more information on the configuration options here.

And just on the off chance that you dont really need the field-picker functionality, but you're just using it to try and get each SimpleResultsTable to show different fields, dont forget that they can be easily set with the <param name="fields">foo bar baz</param> right on SimpleResultsTable.

View solution in original post

SplunkTrust
SplunkTrust

OK. it's a bit of a journey, but here goes.

The FieldPicker module cannot show the fields from a postprocess'ed set of results.

FieldPicker and it's modal popup layer will in all cases just show the fields and breakdowns and top values of the underlying events, the un-postprocess'ed rows.

So to take a trivial example, if none of your postProcess searches actually transform the rows, or add any fields or remove any fields, then it would actually work. But this is an extremely unlikely scenario.

Another example: if a postProcess search transforms the rows, like turns events into a set of rows where each row is a distinct 'user', and you want the FieldPicker to show the fields that are available for the user rows, you're out of luck. FieldPicker will keep showing the fields from the raw events, and it wont show you any of the correct fields.

Another example: if the postProcess search adds or removes a field, the FieldPicker will not show the new field in the first case, and keep showing the unwanted field in the second.

The only glimmer of good news, is that the final output of the FieldPicker module, the only thing it tells the SimpleResultsTable, is a key called "results.fields". So in theory you could have a StaticSelect module (or in sideview_utils a Pulldown module), where each <option> is a combination of fields. This is clunky but might suit your needs if you can boil it down to a couple combinations.

If you're using the Pulldown module from the sideview_utils app, it has a multiple selection mode and in that case you could make it be a simple FieldPicker, where each <option> is a separate field. You can have this list configured statically or you can have it itself come from a postProcess search (. At the end of the day it would output "results.fields" and it would act as a simple little fieldPicker. it of course has no modal popup functionality nor summary statistics nor top 10 values nor much of anything fancy. But ctrl-clicking fields there would indeed effect the SimpleResultsTable downstream. sideview_utils docs has more information on the configuration options here.

And just on the off chance that you dont really need the field-picker functionality, but you're just using it to try and get each SimpleResultsTable to show different fields, dont forget that they can be easily set with the <param name="fields">foo bar baz</param> right on SimpleResultsTable.

View solution in original post

Splunk Employee
Splunk Employee

This was a detailed (and more importantly, useful) answer. I kept trying to modify FieldPicker behavior before finally writing a module called StaticFieldPicker that doesn't know anything about underlying events and only knows about fields passed in through its param. It inherits HiddenFieldPicker to return 'results.fields' based on user selection. It was your mention of 'results.fields' and using Pulldown that motivated me to solve it that way. Somewhat related: I really dig on sideview_utils app too, despite not owning a Sideview t-shirt.

0 Karma