The error is exactly what it says: The interpreter cannot determine values of placeholder tokens $starttime$ and $endtime$ without replace_me arguments. There absolutely are details about savedsearc...
See more...
The error is exactly what it says: The interpreter cannot determine values of placeholder tokens $starttime$ and $endtime$ without replace_me arguments. There absolutely are details about savedsearch command. From opening paragraph in savedsearch: If the search contains replacement placeholder terms, such as $replace_me$, the search processor replaces the placeholders with the strings you specify. For example: | savedsearch mysearch replace_me="value" Before showing a possible fix, I want to warn against using map command against time. It is unclear what starttimeu and endtimeu are. Are these in raw events in index=ix1? Fundamentally, map is often not the best solution to any given problem. Try these two searches, one uses map, one doesn't: To map | makeresults format=csv data="field1v, field2v
aaa, bbb"
| map field1v field2v search="| makeresults format=csv data=\"field1, field2, field3
abc, def, 1
aaa, bbb, 2
xxx, yyy, 3\" | search field1 = $field1v$ field2 = $field2v$" Not to map | makeresults format=csv data="field1, field2, field3
abc, def, 1
aaa, bbb, 2
xxx, yyy, 3"
| search
[makeresults format=csv data="field1v, field2v
aaa, bbb"
| rename field1v as field1, field2v as field2] The output is exactly the same, but the second one is easier to understand and easier to construct. To apply to your problem, if the fields I questioned above all exist in raw events, your search would be better constructed as search index=ix1
[search index=ix2 eventStatus="Successful"
| return 1000 eventID ]
[search index=ix2 eventStatus="Successful"
| localize timeafter=0m timebefore=1m
| fields starttime endtime
| rename starttime as startimeu, endtime as endtimeu]
| stats values(client) values(port) values(target) by eventID Not only does this search not need replacement token, but also it is easier to maintain. In short, to map? Or not to map? That is the question. $xxx$ in saved search is interpreted as replacement tokens whose values must be specified in the invocation command. This contradicts with the map command's use of $xxx$. You can say not differentiating value tokens used in different contexts is a design weakness in SPL. But that's what SPL has today. This is not a bug per se.