Hello,
I have a macro (a subsearch enclosed in square brackets) that I use to filter my initial search. I would like to do some regex magic on the search string that format creates. Unfortunately, if I call format and do parsing on the search field, a second format seems to be implicitly called at the end of the macro, and it encloses the regexed search string in an extra set of quotes and double parentheses, which confuses the outer search. Is there a way either to prevent format from being called at all, or to keep it from enclosing the field in quotes?
Figured it out. I can just call return at the end of the macro and it doesn't reapply the formatting.
Figured it out. I can just call return at the end of the macro and it doesn't reapply the formatting.
Actually, if I use index=null splunk_server=localhost | stats count, that returns relatively quickly--it's the going out to the distributed search peers that makes it take forever. But at any rate, getting the returned macro string correct is my bigger concern.
That's odd on the stats, provided you have no search in front of it the stats just has to go "Oh - no events, print out count=0 and be done!" in no time at all.
stats count actually takes several seconds to return a single event. I can't write the macro as a single eval statement because of the regex requirements, and I have never gotten eval-based macros to work in a more complicated format.
Hmm. Two thoughts - first, you can replace dummy search | head 1
with stats count
to use up zero resources whatsoever and second, have you considered using eval-based macros instead of the subsearch?
I'm playing with parsing input from a dashboard textbox. It's something like this.
[dummy search| head 1 | eval foo="$input$" | rex field=foo "(?
If I run it in the search bar without the brackets and paste the resulting query in my outer search, it works fine. When I call it as a macro, it doesn't. If I run it in the search bar with the square brackets included, it adds an extra ((" and ")) on either side of the string, which I'm guessing is how the search sees it.
When I do this
[gentimes start=-1 increment=8h | fields starthuman | format | eval search = replace(search, "\(", "{") | eval search = replace(search, "\)", "}")]
there is no extra format being called, and splunk's litsearch literally does look for curly braces - what are you doing differently?