Opendistro ES is using mustache template for accessing ctx keys in the trigger action. We have some use cases where we have to compare (but the mustache is a logicless templating script so cannot compare) the value of some keys and then write the actions accordingly.
P.S: We wanted to use a generic monitor extraction (for all hosts) using term aggregation over the host and write different trigger condition and action based on hosts. And there are exclusive slack channels for each host to trigger alerts.
Yes mustache is logic less but there is a way to achieve if else using inverted sections I think this will also depend on how your Hosts are structured in the results.
Sample example from the doc :
{{#repo}}
<b>{{name}}</b>
{{/repo}}
{{^repo}}
No repos :(
{{/repo}}
Like you mentioned this is not possible with Mustache as it does not support logical statements, you might want to work with the passed context variables.
The only real logic you can put into mustache is boolean & existence clauses, which do not aid you in your case.
@mihirsoni@lucaswin-amzn, is it possible to append to the trigger variables in the trigger painless script so that we can access it in the Action Message Body.
I keep getting a compile error when I try to assign to the trigger variables, for example this is the trigger condition script:
My use case is to monitor an index to assert that data points are being emitted from a sensor every hour, so the monitor query is an aggregation that has buckets of unique sensor ids from 2hrs ago and 1hr ago.
I want to alert on doc counts for sensor ids not increment between the hour gap, so the action message would include the sensor ids that triggered the monitor to return true.
Thanks for verifying this, my current workaround would be to sent ctx.resutls.0 to the custom_webhook and handle the alert logic there before passing it over to the alert channels.
@mihirsoni@lucaswin-amzn, Is there a feature request for ability to compare such results in trigger action? If so, could you please provide the github link to follow? If not is there any work around as of now?
This seems to be a must feature, as it forms the basis for filtering out unwanted terms from the alert. Much like transforming payload in xpack