API: is there any plan to implement a REST API into this project?

[fberrez]

Hi,

I am a previous user of bitsensor/elastalert (which is a docker image of yelp/elastalert) and I would like to know if there is any plan to implement a REST API into elastalert2 .

It could be a great thing for CRUD from an external project or even a new rule activation/deactivation feature.

What do you think about that?

[jertel]

I have no plans but perhaps others would be interested in contributing something for this idea.

Alternatively, if you're a slack user you could use the Elastabot project to silence alerts and perform other DevOps-related functions.

[fberrez]

I am a slack user and Elastabot seems to be a good option. I will take a look at it even if I prefer the use of a REST API.
Thank you!

[mrfroggg]

I think it could be a good addition at some point, especially on the snoozing/activation/deactivation part.

[nsano-rururu]

@fberrez

Is it something like the following in a Yelp / elastalert pull request? I didn't think about it at all. The following are made with Flask, should I make them with the Django Rest Framework now?

Added a REST API to List, Create, and Test rules
Yelp/elastalert#656

[fberrez]

I think implementing a REST API could be a good thing for many users who want to implement elastalert in their devops environment.

It could be something like the PR you mentioned or like bitsensor/elastalert which implements an API.

And by adding new routes, it can make elastalert2 more interactive than anything else before.

I will take look at your fork, I can offer you my help if you want to implement something like that ;)

[vvvlad]

@nsano-rururu I would suggest looking into FastAPI for the rest framework, as it has many more advantages over flask and faster (to develop and use) than django as far as I know.

[daiwei233]

good idea

[initharrington]

This would be a great addition to the project in my opinion. Currently, we have a hacky jenkins job that renames the rules files so elastalert stops running them. The reason we have this is so users can "silence" their alerts during some change/deployment. I look at is as the same way alertmanager silences work.