The venerable old-skool Splunk forums are now closed. Feel free to search for old content here, but new posts are no longer supported.

Instead, please visit the thriving community at answers.splunk.com to ask and answer questions about your Splunk deployment and how to get the most out of it.

Forums: SplunkSearchAndAlert: Trying to match a search based on a like Number in two locations

Previous Topic: Boolean expression problem  |   Next Topic: View entire indexed file from a specific date


Posts 1–4 of 4

I have a search string that needs to be matched and only alert when the numbers in the string pair match.
Example:
local node number 2, AND master node number 2

So this only alerts when the number 2 is in both parts of the string.
But, the number could be, 1 and 1, 2 and 2, 3 and 3, or 4 and 4

This has to do with Oracle RAC and understanding which NODE is the master. Whatever node has a matching first number to the second then it is the master.

pstein
aka. p(v4)stein

We are running v3.4.9....Hopefully Q1 will bring us up to v4.x

...and I know I can match the string by doing the following but would rather have a shorter search....if possible.

This works:
"local node number 2, master node number 2" OR "local node number 1, master node number 1" OR "local node number 3, master node number 3" OR "local node number 4, master node number 4"

Regards,

pstein

Well, your best best might actually be:

local node number , master node number | regex _raw="local node number (\d+), master node number \1"

Generally using regex to filter is much less efficient than using the search index. However, for this particular search, the index is only consulted for events containing the terms, while the order and the matching of the numbers is done pretty similarly to using the "regex" command so it should perform similarly.

[Revised on Wed, 13 Jan 2010 09:50:10 -0800]

Oh if you're running 3.x, my suggestion won't quite work if the initial search results set has more than the maxresults, so your "long" search string might be best. That's not an issue in 4.0