I nabbed some searches from our license server/monitoring console and placed them in the search head cluster so that they would be available to some users which should not have access to the monitoring console. The resulting dashboard overview would benefit (heavily) from a "base search" to feed the different panels. However, some of them use "subsearches" and I cannot figure out if i can and then how to combine the two. There are a couple of these searches where you pull some license usage data and available license for different pools or the total license available (hence using the stacksz when checking "all" pools ("*")).   index=_internal source=*license_usage.log* type="RolloverSummary" pool=$pool$ | bin _time span=1d | stats latest(b) AS b by slave, pool, _time | timechart span=1d sum(b) AS "volume" by pool fixedrange=false | join type=outer _time [ search index=_internal source=*license_usage.log* type="RolloverSummary" pool=$pool$ | bin _time span=1d | dedup _time stack | eval licenzz=if("$pool$"=="*", stacksz, poolsz) | stats latest(licenzz) AS "Available license" by _time ] | fields - Temp | foreach * [ eval <<FIELD>>=round('<<FIELD>>'/1024/1024/1024, 3) ]   Different panels use different "stats" and "evals", different "AS" naming and more. There is however one consistent part, the initial search: index=_internal source=*license_usage.log* type="RolloverSummary" pool=$pool$ I figured it would be a good ide to use a base search with this, though I cannot figure out how. Using a larger search including the join and subsearch "sort of works". But getting all the different "stats", "evals" and "AS" to produce the expected output is a nightmare. The initial and smaller base search above is the smallest common denominator. But then I cant figure out how to reference this base in the subsearch for the join? All suggestions are welcome. All the best ... View more

I have been trying to achieve "grouped email recipients" and while it is possible, it just won't behave the way I want with generative commands. For "raw events" it works great to have a macro with an eval setting "recipients" to a list of email adresses and then using $result.recipients$ in the "action.email.to =" Howerver, for things like stats and table, this does not work as the actual values of recipients are not part of the results. So for "table" it works if I include "recipients" in the table, but that looks horrible. This can be sort of demonstrated like so where this works: index="_internal" | `recipients` | dedup log_level | table log_level | fields recipients  And this does not index="_internal" | eval recipients = "[email protected], [email protected]" | dedup log_level | table log_level | fields recipients As recipients is empty So, someone suggested that one could use a savedsearches.conf.spec file to define a token like: [savedsearches] recipients = <string> and then use "recipients" in the savedsearches.conf file as $recipients$. This does not seem to be the case though, I cannot find this documented anywhere and the spec file seems to be more "instructive" than anything. Another suggestion was to define global token directly in the savedsearhes file like: [tokens] recipients = Comma-separated list of email addresses and then use $recipients$ for all "action.email.to = $recipients$" in that file. Though I cannot find the token definition solution here documented anywhere. Are any of these suggestions at all valid? Is there any way to somewhere in the app where the alerts live to define a "token" like "recipients" which can be referenced in all "action.email.to" instances in that file so that I only have to update one list in one place? Or is this a "suggested improvement" I need to submit somewhere 🙂 All the best ... View more

Hello everyone Two parter. First of all, am I correct in assuming that /appname/metadata/local.meta takes precedence over /appname/metadata/local.meta The reason for this question is that while applying changes in a SH cluster from a deployer, changes made to default.meta in an app has no effect and changes in local.meta are retained. Second, what is the best praxis for editing the local.meta file? I think I, at least, need to completely remove the read/write permissions so it falls back on the default.meta file [] access = read : [ ], write : [ ] export = none version = x.x.x.x modtime = tttttttttt.tttttttt Otherwise any future edits made and rolled out will not take effect as there is a local.meta file. Though I was hoping that I could just delete the entire local.meta file? To be clear, the actual question, can I     a) delete the entire local.meta file or do I have to     b) edit out the desired section in the local.meta file? I know I can edit access to alerts/dashboards etc via the GUI though I'd like to edit for everything in the app in one single move from the CLI. All the best // f ... View more

I am fairly confident that there is a clever workaround for this though I am not 100% sure how. I have alerts stored in apps on a deployer which makes use of the email function when triggered. I if I need to add/remove recipients from the email alert I have to manually edit several different recipient lists for several different alerts. What I wan't is a clever way to set up som sort of "list" of recipients which I can name "developers" for instance, and instead of having 20 email adresses as recipients in the alert I could do something like "$devops$". Then just edit recipients at a single location for all alerts instead of each one separately. I hope this is a clear enough explanation for what I am hoping is possible and welcome all suggestions.   ... View more