youjie23 commented on issue #13492:
URL: https://github.com/apache/skywalking/issues/13492#issuecomment-3330119822

   > > 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?
   > 
   > For Elastic and JDBC, I think another new record should be good. And it 
may be better to keep them in another logic table? Which could make the 
existing table unchanged. For BanyanDB, we introduced a new trace storage in 
[#13496](https://github.com/apache/skywalking/pull/13496), which has an 
interesting feature, to keep two kinds of logic entities in one table. In that 
PR, it is segment and attachedEvent(Zipkin and Native Segment). In here, we 
could consider Alarm message and AlarmRecovery message. Those need to share one 
UUID and make them always be queried out once without update.
   > 
   > > 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?
   > 
   > Replied in the above one.
   > 
   > > 5. 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"?
   > 
   > I think it should be different and both of them should have a shared UUID.
   > 
   > FYI [@wankai123](https://github.com/wankai123) 
[@hanahmily](https://github.com/hanahmily) 
[@ButterBright](https://github.com/ButterBright) 
[@mrproliu](https://github.com/mrproliu), I am proposing another use case for 
the new trace module. I think this is very useful pattern to replace update.
   
   Thanks for the guidance. 
   I was self-testing this feature and have now encountered an issue. The 
latest master code in BanyanDBStorageClientshows it is only compatible with 
BanyanDB version 0.9. However, on this [downloads page 
link](https://skywalking.apache.org/downloads/), only the latest 0.8 version is 
available. I'm not quite sure if I should compile one myself?


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

Reply via email to