I have gone through the documentation at Scott Haskell's maps-plus GIT https://github.com/sghaskell/maps-plus/  and .js code for the app https://github.com/sghaskell/maps-plus/blob/master/appserver/static/visualizations/maps-plus/src/maps-plus.js There's the <options> for the cluster colors but these are "range" One / Two / Three types of clusters background and foreground colors. I am not a .js developer but there was no provision for controlling the color of the clusters from the SPL search, e.g. through a field value.   I am going to suggest a new feature in "issues" at Scott Haskells maps-plus GIT that maybe the cluster colors be set according to clusterGroup values, using a pre-defined palette in options   https://github.com/sghaskell/maps-plus/issues/39  and leave it at that.  ... View more

Thank you for that... I had a similar problem, a second dropdown that didn't unset its token when a change was done in the first dropdown. I adapted your solution for my ends.  Say we got a secondary input that does not unset its token when a change was done in the primary input.  There is token_1 and token_2. They are the token in the first (principal) input and the second (secondary) input, respectively. They are both populated by searches. And the values for token_2 depend on the values on token_1. Because the token_2 search is subsidiary to the results of token_1, it literally has $token_1$ as a parameter and cannot work without it. It should also be cleared and a new search launched as soon as token_1 is changed so as to NOT TO give "No Results Found" or worse yet (in the case of a coincidence of token_2 values) mislead the user.  Create a token_1_B that is set to be equal to token_1. *After* you check if the new value of token_1 coincides with the former value, token_1_B. Unset token_2, the secondary if token_1 and token_1_B do not match, which means change. Summarizing: Add this as conditional change to the input on the token_1       <change> <condition match="match($token_1$,$token_1_B$)"> <set token="token_1_B">$token_1$</set> <!--to see if the token changed--> </condition> <condition match="!match($token_1$,$token_1_B$)"> <unset token="token_2"></unset> <unset token="form.token_2"></unset> <set token="token_1_B">$token_1$</set> <!--to see if the token changed--> </condition> </change>   ... View more

Alternatively, you could use the lookup table as usual with | lookup (which seems to be more efficient),  creating a dummy variable host_b. Which will be not-null if the name is in your lookup table. Say you have made a yourhostlookup.csv, which has field host and other fields too.  Then you add this to your search. | lookup yourhostlookup.csv host outputnew host as host_b | where isnotnull(host_b) ``` true if host value is found in the lookup, for host values not in the lookup use |where isnull(host_b)```  | fields - host_b ``` continue without the dummy field...``` It will output the dummy field host_b, which will be not null (and equal to host naturally) if "host" from your original search is found in the lookup table. The filtering is done on the dummy field by |where . In your particular case, you want to check for the host not being there, so you use |where isnull(host_b) . Finish by taking the dummy field out of your search. ... View more

Hi, This is exactly my problem @gerbert. I have overly informative metric_name values (containing what should be dimensions inside them, separated by a ".") and would like to extract shorter ones to aggregate upon. And then use mstats. The trivial difference is that I would extract the new metric and dimension using rex | rex field=metric_name "dim1\.dim2\.(?<dim3>.+?)\.(?<metric_name_short>\w+)" | mstats avg(_value) as val WHERE index=indexz AND metric_name="dim1.dim2.*.*" span=5m by host, metric_name_short , dim3 But this is not allowed. So unless my admin re-indexes our metric index... ... View more