[GitHub] [skywalking] chenmudu edited a comment on pull request #6888: Include event(s) to alarms.

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

chenmudu edited a comment on pull request #6888:
URL: https://github.com/apache/skywalking/pull/6888#issuecomment-831114330


   My personal views are as follows:
   
   The first thing we should determine is the relationship between these Events and Alarms ([it seems that no one discussed with me above](https://github.com/apache/skywalking/pull/6888#discussion_r624622071)), and the need to find out the list of all events that were already in store when the current Alarm occurred.Or just include the corresponding `Type == Alarm Events` (which may be 1 or 2) generated under the current Alarm.
   
   If it is determined in a certain time period with the **Scope (Service/Instance/Endpoint)** related to all events (such as the **Type ==  Start、 Shutdown、 Alarm、 and other, etc.**), it means that there could be multiple event,The amount is unimaginable.
   
   First of all: The richness of so many events is guaranteed, but it is also filled with lists of events that are not too strongly related to the current Alarm.
   
   Next: A list of events that are not too strongly correlated may not be as convenient as the user might expect.
   
   Then: The first thing we should determine for performance concerns is how to query (through endpoints or not).
   
   1. The first is to query all the Alarm Messages at once through the drop-down box as now, and then associate multiple Alarm Messages and multiple Events lists in memory.
   2. The second option is to query the event list when an Alarm Message is queried and paginate it in the front end.
   Only after you decide on these two query modes can you determine how to operate in the backend OAP Server and guarantee excellent performance.
   
   In fact, the above problem is to determine how to establish an accurate and non-redundant relationship between numerous events and the current alarm, but there seems to be no excellent solution at present.
   
   In my opinion, if we want to ensure Alarms and Events' associated data with value, we may have the simplest and most valuable way of association, which is to associate the current event list of `Type == Alarm`.Of course, there is nothing wrong with correlating all the Alarm lists that are matched under the current **Scope**.
   
   To sum up, this is just my personal idea. There may be some mistakes in understanding. I am looking forward to @wu-sheng @kezhenxu94  reply. Thanks a lot.


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

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