You need to clarify the problem.    The need to pass the multiselect values to macros2 Forget multiselect values.  What is this macros2?  If this is yet another macro, SPL syntax forbids you from invoking a macro as parameter of another macro.  Do you mean macros2 represents the value from this multiselect token?  In that case, you cannot use single quote. (The outer quote in your pseudo code is also incorrect.  A macro is invoked by a pair of back ticks (`, not '). It really doesn't matter whether the token is multiselect or of any other type.  The dashboard simply treat the resultant value as a string.  How the string is formatted depends on the INPUT settings, what is the delimiter, whether prefix and postfix are used, whether value prefix and value postfix are used, etc.  In this regard, I don't see any question that can be answered based on your description.

No. Don't try to squeeze everything into one command | stats count, values(*) as * by domain This will give you results groupped by domain. So now you have to filter the results with another command. | where count<=5 And you're home.

Consult your environment's documentation. But seriously - an alert is just a scheduled search. You can't automatically determine which indexes will be used when the search is run. Yes, you can do a search for some common ways of specifying the index (most importantly the literal "index=something" string) but as you think of more ways of specifying the index to search it gets more and more impossible. Apart from simple "index=something" way you can do: 1) index IN (some set) 2) use an alias which will expand to a set of parameters (including index(es)) 3) place a condition on eventtype which can resolve to a condition for index(es) 4) use a subsearch which will dynamically create a index=something parameter (theoretically you can even choose index randomly this way). So you can see that in general case there is no way to reliably determine before running the search which indexes will be searched.

OK. So if your June had 23 working days, you want only sum of the license usage during those 23 days divided by 23, right? You simply count as if the week was 5 days long and completely ignore existence of saturdays and sundays? As you open the licensing report in search, you see something like this: index=_internal [`set_local_host`] source=*license_usage.log* type="RolloverSummary" I suppose if you have a distributed environment you might not have the localhost part but some other form of choosing indexers. Anyway, since it's done right after midnight to calculate summarized amount of license used per day, the search behind the report substracts half a day (43200 seconds) from the _time field and then does binning over _time. And that's pretty much it - the b field contains sum of bytes indexed. Now you only have to filter out the saturdays/sundays (possibly with strftime) and do a stats avg and Robert is your father's brother.

Please define what you mean by "average daily ingest excluding weekends". Do you mean to sum only values from monday to friday and divide by 5 days weekly or do you want to sum values from whole 7 days and divide by 5 days or maybe sum values from 5 days and divide by 7 days? (of course extrapolated to your whole search timerange but I mean how do you wanna treat those weekends).

I think I just answered that.  Splunk is only part of the answer.  After all, Splunk can't show you what isn't indexed.  Therefore, if Splunk doesn't find a blacklisted event then the blacklist probably is working.  Confirm that by looking at Windows Event Viewer to see if a blacklisted event was generated.

values(*) as * means take the values of all other fields and put them into fields by the same name.  So each field that existed before stats will exist after it, but possibly with more than one value in each.