youjie23 commented on issue #13492: URL: https://github.com/apache/skywalking/issues/13492#issuecomment-3302020594
> 1.We need to keep the alarm kernel aware of the triggered status, then when it is recovered, this status should be reset to normal, and a new message should be sent out. A new recovery API should be created. > 2. AlarmRecord is an immutable row. How will you keep this recovery status? And mark triggered the alarm. We were hesitant about how to implement this. I'm currently implementing the recovery notification feature and have some design considerations. I'd like to confirm whether these approaches align with the overall architecture and would appreciate your guidance. 1. Following the practice of services like Prometheus, recovery notifications should include the associated (last) firing alert. Consequently, the data structure for recovery is almost identical to the existing `AlarmMessage`, differing only in status. Could we add a new property to `AlarmMessage`, such as "status" with possible values of "firing" and "resolved" (defaulting to "firing"), to distinguish between alarm triggers and recovery notifications. Alternatively, would it be acceptable to create an `AlarmMessage` subclass like `ResolvedAlarmMessage` instead of copying the code? 2. Rather than modifying already-stored AlarmRecords(firing records), could we instead **append** a new resolved record that contains the data from the last alert? 3. For various hooks (e.g., the DingTalk hook), should we add a new template configuration similar to "text-template" for recovery notifications, for example: "resolved-text-template"? -- 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: notifications-unsubscr...@skywalking.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
