You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dolphinscheduler.apache.org by GitBox <gi...@apache.org> on 2022/05/23 14:06:48 UTC

[GitHub] [dolphinscheduler] SbloodyS commented on issue #10211: [Feature][Alert] Alarm availability improvement

SbloodyS commented on issue #10211:
URL: https://github.com/apache/dolphinscheduler/issues/10211#issuecomment-1134724658

   > > > Hi iamliangdi, thx for opening this issue. It is a good point that ds should have some alert mechanism in case `alert-server` fails itself. May I ask how do u want to improve the availability of `alert-server`? Are u planning to enable users to deploy multiple alert-servers?
   > > 
   > > 
   > > hi, Because I just started looking at the code, limited to ability, my idea is
   > > 
   > > 1. Give the power to deploy multiple alert-servers to users, and we are only responsible for ensuring that they will not send duplicate information;
   > > 2. Send email to users in the fatal errors we catch as much as possible;
   > > 
   > > Because in the process of using it, I found that it stopped serving, but didn't tell me it was leaving
   > 
   > @zhongjiajie @SbloodyS I saw there are tables related to alerting in ds metaDB. Just for double-check, if alert-server fails for some reason and restarted later, during the failure, will alerts still get stored in db and sent as soon as alert-server restarts?
   
   Yes. The alert service consumes very few resources. So i recommand the following two ways to ensure production stability:
   1. Deploy alert server in a single instance.
   2. Using systemd or supervisor to manage the process of ```alert-server```. @iamliangdi 


-- 
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