[GitHub] [dolphinscheduler] CalvinKirs commented on issue #7992: [Feature][Alert] Support PagerDuty Plugin && Alert module judging strategy

[GitBox <gi...@apache.org>]

CalvinKirs commented on issue #7992:
URL: https://github.com/apache/dolphinscheduler/issues/7992#issuecomment-1014212824


   > There is a situation in our scenario. Defined a task and when the task succeeds, send a message to the WeChat group, and call the owner via PagerDuty when the task fails. Call different notification plug-ins with different task statuses.
   > 
   > DolphinScheduler is very suitable for this kind of scenario. It relies on saving the alert strategy in t_ds_alert when triggered like above.
   > 
   > ### 1. Here is the design:
   > #### 1. Add alert_strategy in t_ds_alert table
   > alert_strategy tinyint(4) NOT NULL COMMENT 'Alert strategy: 0 process is successfully, 1 process is failed'.
   > 
   > Save the strategy when the alert is triggered.
   > 
   > #### 2. Add alert_strategy in t_ds_alert_plugin_instance table
   > alert_strategy tinyint(4) NOT NULL COMMENT 'Alarm strategy: 1 process is sent successfully, 2 process is sent failed, 3 process is sent successfully and all failures are sent'.
   > 
   > Add strategy choice when creating alarm instance. The default value is 3 processes is sent successfully and all failures are sent. For compatibility with older versions.
   > 
   > #### 3. Change the code to bind the alert alarm instance strategy to process strategy
   > Bind alarm instance's strategy to t_ds_process_instance's warning_type and t_ds_schedules's warning_type.
   > 
   > When a process with a configured notification strategy triggers an alert. A new record will insert in t_ds_alert table saving the triggered strategy, whether the process is successful or failure. The configured warning group will be triggered. The alarm instance will be triggered one by one.
   > 
   > And there is a new logic. Only process's strategy is matched alarm instance's strategy. The alert will be sent, otherwise, the alert will be ignored.
   > 
   > #### 4. For example
   > When the process's warning_type is 1 process is sent successfully.
   > 
   > And the alarm group has three alarm instances **a & b & c**. The **a's** alert_strategy is **1 process is sent successfully**. The **b's** alert_strategy is **2 process is sent failed**. The **c's** alert_strategy is **3 process is sent successfully and all failures are sent**.
   > 
   > * When the process is **successful**, the alarm instance **a and c** will **send**, the alarm instance **b** will **ignore**.
   > * When the process **fails**, the alarm instances **b and c** will **send**, the alarm instance **a** will **ignore**.
   > 
   > ### 2. Here is the plan:
   > We want to part this solution into three-part.
   > 
   > 1. Add PargerDuty plugin and call API with severity: critical as above
   > 2. Add alert_strategy column in t_ds_alert table & Save the alert strategy when triggered
   > 3. Add alert_strategy column in t_ds_alert_plugin_instance table & Change the login to match strategy
   
   +1, Good job


-- 
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: commits-unsubscribe@dolphinscheduler.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org