ruanwenjun commented on issue #14832: URL: https://github.com/apache/dolphinscheduler/issues/14832#issuecomment-1699232888
> > Why we don't directly use alert module? > > Althougn the Alert module and Listener module have similarities in specific scenarios, such as both supporting to notify users about the execution results of workflows/tasks througn various plugins, there are several key differences: > > 1. **Purpose:** > > * **Alert Module:** The Alert module is designed specifically to inform users about the execution results of individual workflows or tasks (which specfied by the user when running the workflow). The content and format of Alert are fixed. Alerts are sent directly to users via emails, Telegram, Ding Talk, etc. > * **Listener Module:** The Listener module is designed for third-party systems to monitor and manage DolphinScheduler. The listener instances are global which are not limited to specific workflows/tasks, so in addition to the workflow/task related events like workflowStartEvent, workflowFailedEvent, etc., it also provides system-wide events like serverDownEvent, workflowAddedEvent, etc. Users can customize the format and content of messages based on listener events. The messages are sent to Kafka, RabbitMQ, external system interfaces, etc > 2. **Flexibility and Extensibility:** > > * **Alert Module:** Alert Plugins are build-in. When creating a new alert plugin, modifications to source code, repackaging, and service restarts are required. The content and format of Alert are fixed. > * **Listener Module:** The listener module offers more flexbility. We can create a separate project to develop new plugins depended on a single module(`dolphinsheduler-dolphinsheduler-common`) , without modifying the source code. Listener plugins can be installed, updated, or uninstalled online without restarting the server. The listener module also provide more flexibility and convenience to customize the message formats and processing methods. > 3. **Handling Failure** > > * **Alert Module:** The Alert Module won't take any further action when message processing fails. Therefore, from the receiver's perspective, there's a risk of message loss. > * **Listener Module:** Each listener instance has a corresponding ListenerInstancePostService that processes its listener events in chronological order. If message processing fails, the processing of subsequent messages is halted, and retries are attempted. This ensures that messages are neither lost nor unordered. 1. The alert module can also send workflow/task change event and server crash event, and we already have a alert system, it' s not a good idea to add a new listener system, if you want to do some feature you need to design base on alert rather than import a new rule. 3. I don't think `without modify the source code` is a reason to add this feature. 4. Make event don't lost is not a good design, and if you wish to do this you will make ds vulnerable, ds is used to trigger workflow rather than a notify system, each notify task shouldn't affect ds available and workflow result, if a workflow execute success but notify subsystem failed, it should failed and block ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
