Hi folks, I think it will be useful for Alert service supporting the plugin management. I’ve create an issue in Github and described about it, here <https://github.com/apache/incubator-dolphinscheduler/issues/2553> is the link. Copy here for convenience.
> I think the plugin feature is needed by the customers, because different user > may have different environment. For example, I want to use SMS to send alert > information, but the SMS API is provided by some system we don't know before, > and our DS has already deployed. In this case, I just want to implement the > plugin code, and don't change the source code. > > Another benefits are developers can implement different plugin, like slack, > wechat, telegram, github issue, and etc... > > Describe the solution you'd like > A clear and concise description of what you want to happen. > > A better way is that user do not need to change the source code to support > new alert method. Instead, they just need to implement some interface, and > compliance with the convention, then package all(include dependencies) in a > single jar file, and put the jar file in some specific place, such as > $DS_HOME/plugins. After that, when start Alert service, the plugins can be > recognized and loaded. So user can choose the alert method in the portal. > > Currently, I've done some investigations, and if this feature is accepted, I > think maybe I can implement it. > > Firstly, I'd better to adapt the current function, which is send mail and > something like that. > > Then, we can add some more features, such as Alert handler instance, which is > created to describe the alert information(email/slack/wechat/..., to whom, > the title, content, and etc…). > > BTW, email and webhook are used frequently. I think they can be the default > plugin, and written in the source code, instead of a jar file. Thanks, hgaol
