alerting
alerting copied to clipboard
Add support for tags on destinations / monitors
Issue by phillbaker
Saturday Jun 15, 2019 at 13:48 GMT
Originally opened as https://github.com/opendistro-for-elasticsearch/alerting/issues/70
When using the API to configure alerting, it would be helpful to create destinations (and potentially monitors) with tags so that the destinations could be retrieved by searching for a given set of tags.
For example, when creating a new monitor, I might want to re-use the destination for "production" and "team A", but there doesn't appear to be a good way to explicitly label destinations so they can be programatically retrieved.
As a couple of workarounds, I suppose:
- this information could be stored in the name of a destination
- the underlying object in the index could be updated
Related to #56 a bit.
Comment by dbbaughe
Monday Jun 17, 2019 at 17:08 GMT
Hi @phillbaker,
We are definitely missing a GET Destination API which would help, but to further clarify on your issue are you looking for a way to tag and group destinations or a way to simplify the API creation workflow when adding a destination?
I know when using the API to configure alerting we do require the destination ID in the action configuration which can be annoying to get. It seems like it might be easiest to allow the user to either uniquely tag the destination or even provide the destination document_id used so that they can directly refer to that inside the alerting config.
Comment by phillbaker
Tuesday Jun 18, 2019 at 00:54 GMT
Thanks for taking a look @dbbaughe, I conflated a few issues, happy to add more examples if it'd help.
to further clarify on your issue are you looking for a way to tag and group destinations or a way to simplify the API creation workflow when adding a destination?
A way to tag and group destinations!
it might be easiest to allow the user to either uniquely tag the destination
Agreed - tags and a search endpoint (similar to monitors) would be a big step in this direction.
Follow up question: within the Elasticsearch "watcher" context a user can set the _id
on his own (nevertheless it needs to be unqiue). This allows easy management of destinations/monitors via IaC and Git Pipelines and no need to somehow identify a destination or monitor for an update.
Therefore, it would be useful not only to make destinations/monitors searchable by tag but let a user also set an unique _id
.