Splunk Search

Limitations with searchmatch() eval function?

Lowell
Super Champion

Is there any weird issues with using multiple searchmatch() expressions within a single eval command?

I have a transaction search in which I'm using an eval to assigning my transaction a simple Pass/Fail kind of field. The transactions are summarized and shown on a table in a dashboard. It occurred to me, based on some newly encountered failure scenarios, that I could use splunk to elaborate on the status a little and look for a few specific failure situations, which is when I ran into some trouble...

My original pass/fail logic was like so:

... | eval complete=if(searchmatch("Building Transmission") AND searchmatch("\"sent to Trading Networks\""), "True", "False")

So to expand on this, I decided to use case() rather than if() to easily handle additional status values. I ended up with a search command like this:

... | eval status=case(
    searchmatch("B2B.Invoice.Admin:recoverFailedTransmission -- Sucessfully"), "Removed",
    searchmatch("Systematic failure"), "System Failure",
    (searchmatch("Building Transmission") AND searchmatch("\"sent to Trading Networks\"")), "OK",  
    0==0, "Incomplete")

However, this results in nearly all the transactions being incorrectly assigned the status of "Removed" (the very first condition.) Another event was marked with "Incomplete", when it should have been marked with "System Failure". So basically I got a bunch of incorrect results.

However, if I write my eval using a couple more match()s and less searchmatch()s, then the same logic above seems to work:

... | eval status=case(match(_raw, "(?ms).*? B2B\.Invoice\.Admin:recoverFailedTransmission -- Sucessfully .+"), "Removed",
    match(_raw, "(?ms).*? Systematic failure .*"), "System Failure",
    (searchmatch("Building Transmission") AND searchmatch("sent to Trading Networks")), "OK", 
    0==0, "Incomplete")

This is why I'm wondering if I'm running into some weird limitation. Can anyone see a problem in my logic?

Has anyone used a series of searchmatch() expressions like this before successfully?


Update:

I've also tried breaking apart the search to separate out the various searchmatch() commands. This approach also works, even if it is a bit tedious:

... | eval status_removed=if(searchmatch("B2B.Invoice.Admin:recoverFailedTransmission -- Sucessfully"),1,0)
    | eval status_sysfail=if(searchmatch("Systematic failure"),1,0)
    | eval status_bt=if(searchmatch("Building Transmission"),1,0)
    | eval status_tn=if(searchmatch("\"sent to Trading Networks\""),1,0)
    | eval status=case(status_removed==1, "Removed", status_sysfail==1, "System Failure",  (status_bt==1 AND status_tn==1), "OK",  0==0, "Incomplete")
    | fields status*

bojanz
Communicator

Your second example appears to be incorrect:

. | eval status=case(
searchmatch("B2B.Invoice.Admin:recoverFailedTransmission -- Sucessfully"), "Removed", 
searchmatch("Systematic failure", "System Failure"),  
(searchmatch("Building Transmission") AND searchmatch("\"sent to Trading Networks\"")), "OK",  
0==0, "Incomplete")

See the searchmatch in the second line? Shouldn't it be something like:

searchmatch("Systematic failure"), "System Failure",

(notice the parenthesis)

0 Karma

Lowell
Super Champion

Good catch. Unfortunately that was simply a posting bug on my part. I've corrected the example above, and tried re running it (just to be sure) but I'm still getting the same wacky results with search #2. Any other ideas?

0 Karma
Get Updates on the Splunk Community!

Dashboard Studio Challenge - Learn New Tricks, Showcase Your Skills, and Win Prizes!

Reimagine what you can do with your dashboards. Dashboard Studio is Splunk’s newest dashboard builder to ...

Introducing Edge Processor: Next Gen Data Transformation

We get it - not only can it take a lot of time, money and resources to get data into Splunk, but it also takes ...

Take the 2021 Splunk Career Survey for $50 in Amazon Cash

Help us learn about how Splunk has impacted your career by taking the 2021 Splunk Career Survey. Last year’s ...