Splunk Search

Using Wildcard as value in a variable

Communicator

Is there any way to use a wildcard as a value to a variable?

| inputlookup Functionalities.csv
| search AppNo=$app$
| eval Functionality=AppNo.".".FuncNo." - ".Functionality
| sort Functionality

$app$ has value of * sometimes, or it might have a number. It works with all numbers, or if i type search AppNo="*", but not when $App$=*

I've tried match(), like(), nothing works.

How can i use a variable's wildcard value as a wildcard?

Chris

Tags (2)
0 Karma

Esteemed Legend

The behavior of if, eval, and where is to treat * as a string literal. It is only search and like that treat it as a wildcard. You can switch from where to search and it will work.

0 Karma

Communicator

this is good to know, thanks; however, did you state that last part backwards? search is actually what doesn't work. where, however, works.

0 Karma

Esteemed Legend

Try it yourself; test this search:

index=_* 
| search sourcetype="splunk*"

Against this search:

index=_* 
| where sourcetype="splunk*"

And this search:

index=_* 
| where like(sourcetype, "splunk*")

You are talking about the last one, I am talking about the first 2. Your initial search absolutely should have worked.

0 Karma

Communicator

you're right about search and where, however, the test is not the same. i think what i'm saying, in my example, is that if the * had to be extracted from a variable, then it will be treated as a literal, even in search. it's almost like it's trying to do this (notice the escape char) if the value was extracted from a variable that's absent here, or token actually.

index=_*  | search
sourcetype="splunk\*"

i can tell you my initial query absolutely does not work. normally I modify what i post from the actual but in this example, it is the exact one, so no inadvertent modifications upon using it. i created a tiny dashboard with both your query and mine. yours works, as you claim it should, and mine doesn't. in yours, it's extracting the * from the token and using it as a wildcard, but in mine it doesn't. the only difference is the AppNo is coming from a lookup table instead of a log file.

below is the tiny dashboard used to compare. to test, though, you may have to change the queries slightly and create an actual lookup table with "AppNo", "FuncNo", "Functionality" with values 1, 1, whatever. I expect to get the values of the lookup table in my query (the first one) like i get values in my log file from yours (the bottom one)

Test Dash

<input type="dropdown" token="app" searchWhenChanged="true">
  <label>Application</label>
  <choice value="None">None</choice>
  <choice value="*">All</choice>
  <search>
    <query/>
    <earliest>-24h@h</earliest>
    <latest>now</latest>
  </search>
  <default>None</default>
  <initialValue>None</initialValue>
</input>


<panel>
  <html>
  <h4>app: $app$</h4>
</html>
</panel>


<panel>
  <table>
    <search>
      <query>| inputlookup Functionalities.csv | search AppNo=$app$</query>
      <earliest>-24h@h</earliest>
      <latest>now</latest>
    </search>
    <option name="drilldown">none</option>
  </table>
</panel>


<panel>
  <table>
    <search>
      <query>index=* earliest=-10m@m latest=-0m@m | search sourcetype=$app$</query>
      <earliest>-24h@h</earliest>
      <latest>now</latest>
    </search>
    <option name="drilldown">none</option>
  </table>
</panel>
0 Karma

Esteemed Legend

I am beginning to suspect that somebody may have changed a setting causing different behavior in search that we all know and love. I have NEVER seen what you are describing before and I have seen just about everything. Spin up a Splunk sandbox (it is free) and try it there. Something is VERY fishy here.

0 Karma

Communicator

good idea. ill use another env. I'll try to find some time.

0 Karma

Communicator

I got this working using where like(), which requires double quotes and %.

| inputlookup Functionalities.csv
| where like(AppNo, "$app$")

$app$ can contain a number or a % and it will pull either the entire csv or a subset of it.

For those where a * value works, that is certainly easier, but for me, for some unknown reason, wildcard asterisks act as literals when its a value of a variable. If this is the case for you, this is a 2nd way to write it.

Contributor

Hi,
You can try putting your token in " ". So your search should look like
...| search AppNo="$app$"

0 Karma

Communicator

I tried this as well. I have found a workaround using like() that I will post, but it has the double " that you mention as necessary.

0 Karma

Esteemed Legend

I do not understand what the problem is. I do this all the time and if you do:

...  | search AppNo="$app$"

Where $app$ contains stuff like * or microsoft* or *micro* and it works just fine. What is the probelm?

0 Karma

Communicator

perhaps it is related to the version of splunk. luckily this is a simple test so i can attest this does not work on our version 6.6.10.2b5f6c3d5f96

0 Karma

Communicator

this reputation crap is terrible. i can't correct the above to html encode the asterisk. please re-read the value of $app$ as "*"

0 Karma

Esteemed Legend

I fixed it for you. You do not need HTML. Read the markup link over on the right side.

0 Karma

Communicator

thanks! that works better. apparently i can ask a question but not edit it right after.

0 Karma

Influencer

Can you try your search like this
|search AppNo = “$app$”

0 Karma