I get the following error for the export search example (CYA_Export_For_Core_Splunk_Query).
Seems to be due to fields list feed into
| foreach ... tag* ...
[ eval "<<FIELD>>"=if(mvcount('<<FIELD>>')>1, mvjoin('<<FIELD>>', ","), '<<FIELD>>')]
22 errors occurred while the search was executing. Therefore, search results might be incomplete. Hide errors.
Failed to parse templatized search for field 'tagged.action=failure'
Failed to parse templatized search for field 'tagged.action=success'
Failed to parse templatized search for field 'tagged.app=/network/ntp:default'
...
Hi @JykkeDaMan,
I apologize for this taking so long. The foreach command that is throwing the Failed to parse templatized search for field
message is turning anything that is multivalued into a single values comma separated field. Fortunately for us, none of the tagged.*
fields can return multivalued results. If you are concerned about that you can confirm that with this search:
| rest splunk_server="local" "/servicesNS/-/-/saved/ntags" | eval Type="List by tag name" | fields - type
| foreach tagged.*
[where mvcount('<<FIELD>>')>1]
That search does not get that Failed to parse templatized search for field
message and I am not seeing any results return with it.
I have recreated the error using the same Splunk_SA_CIM app on my local install and I can confirm it does not truncate any of the tagged.*
fields from the results. I also tested the CYA export output with the CYA import query and confirmed that the curl statements it creates functioned properly for the 'tagged.action=failure', 'tagged.action=success', and 'tagged.app=/network/ntp:default' fields. I am going to update the CYA documentation with this information where you can safely ignore any of the Failed to parse templatized search for field
messages for tagged fields. Please let me know if you run into any issues where you do find missing information.
Hi @JykkeDaMan,
I apologize for this taking so long. The foreach command that is throwing the Failed to parse templatized search for field
message is turning anything that is multivalued into a single values comma separated field. Fortunately for us, none of the tagged.*
fields can return multivalued results. If you are concerned about that you can confirm that with this search:
| rest splunk_server="local" "/servicesNS/-/-/saved/ntags" | eval Type="List by tag name" | fields - type
| foreach tagged.*
[where mvcount('<<FIELD>>')>1]
That search does not get that Failed to parse templatized search for field
message and I am not seeing any results return with it.
I have recreated the error using the same Splunk_SA_CIM app on my local install and I can confirm it does not truncate any of the tagged.*
fields from the results. I also tested the CYA export output with the CYA import query and confirmed that the curl statements it creates functioned properly for the 'tagged.action=failure', 'tagged.action=success', and 'tagged.app=/network/ntp:default' fields. I am going to update the CYA documentation with this information where you can safely ignore any of the Failed to parse templatized search for field
messages for tagged fields. Please let me know if you run into any issues where you do find missing information.
Nice solution, I've been planning to review your conf presentation as well as I have a more complicated solution for this (Version Control for Splunk)
Perhaps you should put these notes onto the github repo by opening and closing an issue with this answer? That way it doesn't disappear from the github project...
Thanks for the note. That's actually exactly what I did!
It is coming from:
| rest splunk_server="local" "/servicesNS/-/-/saved/ntags"
For example from the app Splunk_SA_CIM:
"eai:acl.app" = "Splunk_SA_CIM"
"title" = "failure"
"author" = "nobody"
"eai:acl.owner" = "nobody"
"id" = "https://127.0.0.1:8089/servicesNS/nobody/Splunk_SA_CIM/saved/ntags/failure"
"tagged" = "action=failure"
"tagged.action=failure" = "action=failure"
"tagged.action=success" =
"tagged. ..." =
Hi @JykkeDaMan, Thanks for sending out this question. I am going to take a look at this today and will get back to you. At first blush it looks like potentially foreach is failing due to the "=" sign in the field name, but I would have though the double quotes on the left side of the eval and single quotes on the right side should have handled that. I'm adding @efavreau to this to see if he can dig in too.