When I try to use a macro in place of a group of filters in a saved search, Splunk gives me
"Encountered the following error while trying to update: In handler 'savedsearch': `macro-name`,"
macro-name is a string with a literal dash (
-). I am nearly certain that I've seen saved searches containing macros.
I first tried to save from "Edit -> Open in search -> Save". There, the "full" version and the version with macro are tested to have the correct syntax as well as desired result. After getting the error, I went directly in "Settings -> ..." to edit. But upon "Save", it gives the same error.
In addition to having a literal dash in macro name, another possible singularity is the use of an argument (as required by the macro).
First, I would never use a dash ("-") in a name in Splunk: not for a field, a macro or anything else. Sometimes it works and other times it causes hassles or even errors. Use only letters, numbers and underscore ("_") for your names and avoid weirdness. Start names with a letter. These are old rules, but they have never failed me.
Second, if your macro has an argument, make sure the argument is properly defined in the macro. That includes the addition of
(1) to the name of the macro. I think that it would be weird for this to be the problem, but that is worth checking too.
Saved searches can definitely contain macros.
Thanks for the answer. I suspected that special characters in namespace could be a hazard. Then I was encouraged by many examples. (Yes, field names, too). I can understand that allowing dash in field names has practical advantages. But why allow them in strictly user-generated objects such as macro names? If the rulebook says yes, then some rule engines allow it and some deny it, that's a bug.
As to argument, the macro is tested with no problem. Can't say that I have seen saved searches with macros with argument. But again, if that is not to be allowed, the error message should be explicit. At the very minimum, this should be documented somewhere.
I agree that inconsistency is not a good thing! And I agree that a lot of the error messages are not helpful.
I have seen many saved searches using macros with arguments - if you look at the searches and dashboards from apps on SplunkBase, you will see them!
Dashes in field names can come from auto-extraction, so that's one reason that they are supported. But they can lead to real problems, for example:
... | eval x = error-rate | ...
Which leads to ambiguity: are you subtracting the value of the rate field from the error field? Or is "error-rate" just a field name. In some places, you would need to put double quotation marks
" around this field name, but in an
eval command, you must use single quotation marks
This is why I follow my "old rule" above - then I never have to worry with this stuff.
Ran across this issue with a saved search that was shared in the app and a macro that was private. Making the macro shared in the app fixed the issue of not being able to save the modified search with the macro in it. Check the permissions of the knowledge objects used in your search.
local.meta in the $SPLUNKHOME/etc/apps/[appname]/metadata directory prevented in my case that my saved searches can execute the macro. I deleted the file and it worked.
Even more amazingly, for reference to others who're looking, the dash in macro name does not prevent it from being saved into a panel! So you can use such a macro in a dashboard but not for alert.