Duansg commented on issue #3757: URL: https://github.com/apache/hertzbeat/issues/3757#issuecomment-3303390482
> This part is not described in detail in the official documentation. I suggest supplementing the documentation. > > Back to the previous question: > > 1. If an alarm has already resolved and then fires again, it will take at least the `repeat interval` for the first alert to appear. For example, if the `repeat interval` is set to 4 hours, and the alarm resolves at the 10th minute, and firing again at the first hour, the notification will not be sent until the 4h + 10m. Will this result in delayed notifications? > 2. An alert that fires only once is not affected by the repeat_interval and does not send repeated notifications. Is this by design, or was this scenario not initially considered? > If the alert source is Hertzbeat's built-in system, it performs periodic checks, meaning an unresolved issue will be triggered continuously. However, when using an external source, it's possible for an error to fire only once at the beginning and then only send a single resolve notification when the issue is fixed. First, thank you for your suggestions. We will gradually improve the relevant documentation in the future. Second, regarding the two questions you raised again: 1. I believe this is reasonable. The lifecycle of your initial alert has already concluded with the first recovery. The second alert triggered must adhere to the `repeat_interval` configuration. 2. You're absolutely right. In the current design, since `repeat_interval` depends on alarm occurrence, even external integrations must adhere to the existing alert notification lifecycle. If an external alert occurs only once, and if your solution involves sending notifications at regular intervals, but the external source fails to send recovery notifications due to certain issues, then you must consider how to terminate this "looping" notification process. Otherwise, it will enter an endless loop. This represents a trade-off point. Consider implementing options like `periodic alerts` and `triggered alerts` for user selection. Alternatively, refactor the alert processing logic to handle all alerts as `periodic alerts`, while adding a cleanup feature for `aggregate groups`. Allow users to choose whether to perform cleanup to prevent infinite notification loops. However, these functional points deviate from your current issue. We recommend submitting a new issue to distinguish and track problems effectively. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
