Splunk Search

Is my map search being parsed before variable substitution?

mlf
Path Finder

Having issues with the following:

| map search="search index=summary search_name=\"$summary_search$\" $summary_selector$"

It returns the expected results when $summary_selector$ evaluates to a simple string, "Foo" or "Bar=Foo", but silently fails in cases where it contains a space, or multiple space-separated terms, "Bar=Foo " or "Bar=Foo Baz=xxx". This leads me to believe that the map search is being parsed before variable substitution and $summary_selector$ is being forced to a string literal. I.e. it seems the search is evaluated as:

search index=summary search_name="Mysearch" "Bar=Foo Baz=xxx"

rather than the intended:

search index=summary search_name="Mysearch" Bar=Foo Baz=xxx

Can anyone confirm the parsing/substitution order or suggest a workaround?

0 Karma

jplumsdaine22
Influencer

Are those variables field names from the previous search command? With Map $field$ should evaluate to the value for field for each input to the map command.

So if you summary_selector is a multivalue field, then split it first and then change your map. Something like this:

rex yourMVfield="Foo=(?<Foo>foo?)Baz=(?<Baz>baz?)"  | map search="search index=summary search_name=$summary_search$ Foo=$Foo$ Baz=$Baz$"

See 'Usage' at http://docs.splunk.com/Documentation/Splunk/6.3.2/SearchReference/Map

Also, theres a good chance you don't need map at all depending on what your base search is.

0 Karma

mlf
Path Finder

$summary_search$ would be the name of a populating search. $summary_selector$ would be part of a search string used to select data from the summary for forecasting. The use case is something like this:

| localop
| rest /services/saved/searches 
| search title="XYZ - Predict - ATM volume" 
| rex field=search "search_name=\"(?<summary_search>[^\"]+)\" (?<summary_selector>[^\|]+)" 
| rename title as forecast_search 
| map search="search index=summary search_name="$forecast_search$" OR (search_name="$summary_search$" $summary_selector$) 
   | timechart span=10m sum(low) as low, sum(pred) as forecast, sum(high) as high, sum(count) as actual "

where the "* - Predict - *" search is of the form:

index=summary search_name="XYZ - Summary - Count by Type and Action" MessageType=Atm
| timechart span=10m sum(count) as count
| `predict5w(count, 90, +1d, 1)`

The basic idea is a form that lets the user select a forecasting (* - Predict - *) search, gets the underlying summary search and selection criteria, and displays the actual (summery) vs forecast data for that metric. In this example, summary_selector="MessageType=Atm " so the search fails. If I adjust the regex so summary_selector="MessageType=Atm" it works, but only because MessageType=Atm is functionally equivalent to "MessageType=Atm" for this particular search. In the case where summary_selector="MessageType=Atm Action=Denied", the search would fail since "MessageType=Atm Action=Denied" is not equivalent to MessageType=Atm Action=Denied.

I figured out one possible workaround using a where/searchmatch clause in the map search:

| localop 
| rest /services/saved/searches 
| search title="XYZ - Predict - ATM volume" 
| rex field=search "search_name=\"(?<summary_search>[^\"]+)\" (?<summary_selector>[^\|]+)" 
| rename title as forecast_search
| eval filter="search_name=\"".forecast_search."\" OR (search_name=\"".summary_search."\" ".summary_selector.")"
| map search="search index=summary search_name=\"$forecast_search$\" OR search_name=\"$summary_search$\" | where searchmatch($filter$) | timechart span=10m sum(low) as low, sum(pred) as forecast, sum(high) as high, sum(count) as actual "

I'm still checking edge cases, but it seems to work so far. Not as efficient as it could be though.

0 Karma

jplumsdaine22
Influencer

OK I see.

Well you can tokenize the search with the following logic

| localop 
| rest /services/saved/searches 
| search title="XYZ - Predict - ATM volume"\
| makemv delim=" " search
| table search 
| mvexpand search 
| rex field=search "(?<key>\w+?)=(?<value>.*)" 
| eval {key}=value 
| fields - key value search 
| stats values(*) as *

The problem is it will be hard to use that with map. I would try using a subsearch instead

0 Karma
Get Updates on the Splunk Community!

Monitoring MariaDB and MySQL

In a previous post, we explored monitoring PostgreSQL and general best practices around which metrics to ...

Financial Services Industry Use Cases, ITSI Best Practices, and More New Articles ...

Splunk Lantern is a Splunk customer success center that provides advice from Splunk experts on valuable data ...

Splunk Federated Analytics for Amazon Security Lake

Thursday, November 21, 2024  |  11AM PT / 2PM ET Register Now Join our session to see the technical ...