Splunk Search

Using Wildcard as value in a variable

weidertc
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

woodcock
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

weidertc
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

woodcock
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

weidertc
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

woodcock
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

weidertc
Communicator

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

0 Karma

weidertc
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.

nikita_p
Contributor

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

0 Karma

weidertc
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

woodcock
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

weidertc
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

weidertc
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

woodcock
Esteemed Legend

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

0 Karma

weidertc
Communicator

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

0 Karma

Vijeta
Influencer

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

0 Karma
Get Updates on the Splunk Community!

Happy CX Day to our Community Superheroes!

Happy 10th Birthday CX Day!What is CX Day? It’s a global celebration recognizing innovation and success in the ...

Check out This Month’s Brand new Splunk Lantern Articles

Splunk Lantern is a customer success center providing advice from Splunk experts on valuable data insights, ...

Routing Data to Different Splunk Indexes in the OpenTelemetry Collector

This blog post is part of an ongoing series on OpenTelemetry. The OpenTelemetry project is the second largest ...