All Apps and Add-ons

Sideview if statement to assign a new token

Path Finder

so here's my problem,
i have timecharts of failed authentications for the past hour. i drilldown off of that with a sideview Pulldown list to show either users or hosts at the selected time window. at this point i want to drilldown again.

here's the rub, i need this new drilldown to take the token of the first, and top value by the second option. let me give an example..

i have two options on the first drilldown, top host, or top user. my second drilldown will take the selected value (say userX) and _time add them to the search, then take the token from the first drilldown and assign a second token based on the value (ie token 1 = user, so eval s=if(token1="user", host, user)) and use the second token to TOP the search.

any help you all can give is greatly appreciated.


UPDATE:

maybe i should re-clarify, the search part of the drill down is not the problem. its when im using the top values function to sort by the opposite of what the selected pulldown was.

(index=windows_security EventCode="4625") OR (index=unix OR index=unix_secure eventtype="failed_login" host!=snmpprod*) $selectedSort2$="$click.value$" | eval sort = if("$selectedSort2$"="host", "Account_Name", "host") | top $sort$

but $sort$ doesnt work, but the eval function is working.. any thoughts?

1 Solution

SplunkTrust
SplunkTrust

Let me see if I can restate again, to see if I understand.

You've got your timechart of failed authentications. It has inline drilldown, and when the user clicks it, downstream from it there is then a Pulldown giving them a choice of analyzing the drilldown either "by user" or "by host". If they pick "by user", then the table beneath will show users, if "by host" it'll show hosts. When this second Table is clicked, you need a second drilldown search to search for user="bob" or host="host17" as appropriate given what the user has picked in both Pulldown and Table.

Let me know if I've got it right and I'll edit this answer to show you how.


UPDATE:

OK. Let's fill in some more specifics and say the "by users"/"by hosts" Pulldown has a "name" param of "drilldownType", and that the "name" param of the Table is left blank so its gonna have the default "$row.*$" tokens.

If the users and hosts are the first column in the Table, then we have it easy. We can just refer to using the legacy $row.value$ token, as follows:

<module name="Search">
  <param name="search">foo bar baz $drilldownType$="$row.value$"</param>

If it's not, we can use the $row.cellN$ syntax. For instance if it's in the third column:

<module name="Search">
  <param name="search">foo bar baz $drilldownType$="$row.cell2.value$"</param>

If you really really need to have a single $foo$ token take on two different values conditionally (we don't actually need that here), that can be done with a pair of ValueSetters, each with the same "name" param, setting the value two different ways, using the "requiredKeys" param on both, and with the more downstream of two setting its "allowClobber" param to False. (If you read the ValueSetter docs and examples this vague description will become clear. )

Further reading: The Sideview Utils app has prety extensive docs for Table, also for ValueSetter, and there's even a whole page dedicated to running through all the $foo$ tokens available across the whole system. If you ever want to dissect a living view and see what tokens are available at what point, check out the "Runtime Debug" mode of the Sideview Editor...

As always you can get the latest Sideview Utils for free, only from the Sideview website.
http://sideviewapps.com/apps/sideview-utils

And there's a mailing list now so users can stay more on top of updates - http://sideviewapps.com/apps/sideview-utils/mailing-list/

UPDATE 2:

OK, for the additional nuance, whereby when the user picks "host", the drilldown filters by host="clickedUponHost" AND the drilldown search knows to do "top user" (and when the user picks "user", the drilldown search filters by user="clickedUponHost" and the drilldown search does "top host").... here goes. There are several ways.

First, the reason you're confused is you're thinking the $foo$ tokens are somehow connected to the field names in the search results. They're sort of analogous, but they're separate spaces. So when you create that field called "sort", it's a field that lives in the search results, and it has no relation to the $sort$ token that you're referencing in the UI.

Way 1) Make the AccountName/host Pulldown actually output two keys at a time instead of one. It's a little strange and clunky, but you can rig up a static Pulldown module to effectively output any number of keys. There is a docs page in Sideview Utils dedicated entirely to this advanced topic. Look in the app's navigation menu under "pulldown module". So here the values would be "host,Account_Name", vs "Account_Name,host". The docs page will show you the rest, but you basically get two usable tokens instead of 1. This is probably the best way although it's a bit odd.

Way 2) Make a single stable name. eval name=if(selectedSort=="host",Account_Name,host) | top name It's not great because it'll always say "name" and never "host" vs "Account_Name"

Way 3) Also very strange. Abuse postProcess a little, to get a single postprocessed row with a single field name that is variously "Account_Name" or "host". Then nest a ResultsValueSetter module inside the postprocess to pull down this value and make it available as a $foo$ token. (That's what ResultsValueSetter does, it provides a way for field values to magically become present in the UI as $foo$ tokens), then use another postprocess to do "| top $fieldThatIPulledDownWithResultsValueSetter$." There is a page of documentation dedicated to the ResultsValueSetter module as well as a working example that will help you understand how it works.

View solution in original post

SplunkTrust
SplunkTrust

Let me see if I can restate again, to see if I understand.

You've got your timechart of failed authentications. It has inline drilldown, and when the user clicks it, downstream from it there is then a Pulldown giving them a choice of analyzing the drilldown either "by user" or "by host". If they pick "by user", then the table beneath will show users, if "by host" it'll show hosts. When this second Table is clicked, you need a second drilldown search to search for user="bob" or host="host17" as appropriate given what the user has picked in both Pulldown and Table.

Let me know if I've got it right and I'll edit this answer to show you how.


UPDATE:

OK. Let's fill in some more specifics and say the "by users"/"by hosts" Pulldown has a "name" param of "drilldownType", and that the "name" param of the Table is left blank so its gonna have the default "$row.*$" tokens.

If the users and hosts are the first column in the Table, then we have it easy. We can just refer to using the legacy $row.value$ token, as follows:

<module name="Search">
  <param name="search">foo bar baz $drilldownType$="$row.value$"</param>

If it's not, we can use the $row.cellN$ syntax. For instance if it's in the third column:

<module name="Search">
  <param name="search">foo bar baz $drilldownType$="$row.cell2.value$"</param>

If you really really need to have a single $foo$ token take on two different values conditionally (we don't actually need that here), that can be done with a pair of ValueSetters, each with the same "name" param, setting the value two different ways, using the "requiredKeys" param on both, and with the more downstream of two setting its "allowClobber" param to False. (If you read the ValueSetter docs and examples this vague description will become clear. )

Further reading: The Sideview Utils app has prety extensive docs for Table, also for ValueSetter, and there's even a whole page dedicated to running through all the $foo$ tokens available across the whole system. If you ever want to dissect a living view and see what tokens are available at what point, check out the "Runtime Debug" mode of the Sideview Editor...

As always you can get the latest Sideview Utils for free, only from the Sideview website.
http://sideviewapps.com/apps/sideview-utils

And there's a mailing list now so users can stay more on top of updates - http://sideviewapps.com/apps/sideview-utils/mailing-list/

UPDATE 2:

OK, for the additional nuance, whereby when the user picks "host", the drilldown filters by host="clickedUponHost" AND the drilldown search knows to do "top user" (and when the user picks "user", the drilldown search filters by user="clickedUponHost" and the drilldown search does "top host").... here goes. There are several ways.

First, the reason you're confused is you're thinking the $foo$ tokens are somehow connected to the field names in the search results. They're sort of analogous, but they're separate spaces. So when you create that field called "sort", it's a field that lives in the search results, and it has no relation to the $sort$ token that you're referencing in the UI.

Way 1) Make the AccountName/host Pulldown actually output two keys at a time instead of one. It's a little strange and clunky, but you can rig up a static Pulldown module to effectively output any number of keys. There is a docs page in Sideview Utils dedicated entirely to this advanced topic. Look in the app's navigation menu under "pulldown module". So here the values would be "host,Account_Name", vs "Account_Name,host". The docs page will show you the rest, but you basically get two usable tokens instead of 1. This is probably the best way although it's a bit odd.

Way 2) Make a single stable name. eval name=if(selectedSort=="host",Account_Name,host) | top name It's not great because it'll always say "name" and never "host" vs "Account_Name"

Way 3) Also very strange. Abuse postProcess a little, to get a single postprocessed row with a single field name that is variously "Account_Name" or "host". Then nest a ResultsValueSetter module inside the postprocess to pull down this value and make it available as a $foo$ token. (That's what ResultsValueSetter does, it provides a way for field values to magically become present in the UI as $foo$ tokens), then use another postprocess to do "| top $fieldThatIPulledDownWithResultsValueSetter$." There is a page of documentation dedicated to the ResultsValueSetter module as well as a working example that will help you understand how it works.

View solution in original post

Path Finder

perfect! thanks sideview

0 Karma

SplunkTrust
SplunkTrust

Oh goodness. I see. When the user picks one of the two, you want to filter by it, but also group the events by the other one. Two ways to do it. I'll update my answer, again.

0 Karma

Path Finder

maybe i should re-clarify, that part of the drill down is not the problem. its when im using the top values to sort by the opposite of what the selected pulldown was.

(index=windows_security EventCode="4625") OR (index=unix OR index=unix_secure eventtype="failed_login" host!=snmpprod*) $selectedSort2$="$click.value$" | eval sort = if("$selectedSort2$"="host", "Account_Name", "host") | top $sort$

but $sort$ doesnt work, but the eval function is working.. any thoughts?

0 Karma