wu-sheng commented on pull request #6888: URL: https://github.com/apache/skywalking/pull/6888#issuecomment-831125391
@chenmudu Let me be clear about these ## The comments I made You are querying all events, even binding to the scope still could impact the performance match. 1. If you take a look at UI, we could query all scopes' alarm messages. So this kind of filter is pointless. 2. We are only querying limited alarms at one time, so, we could definitely query related events after we have the alarm list. ## Your questions about the relationship and correlation > The richness of so many events is guaranteed For a specific entity, there is no chance to have too many events. Could you share why you feel this way? My arguing is you are querying all events of a given scope, rather than an entity. Take the above (1). An alarm is according to the metrics, rather than events, so, they are NOT a direct causal relationship. Logically you could be, such as a redeployment brings the codes with a performance issue in the runtime, which reduces the process capability, then increase the latency. But only we know event and alarm binding within a certain time window and take a look at the codes, we know that for sure. This is not about the solution, This example shows you, alarm + event is leading users in the right direction to find the issue, we are not doing it internally. So, basically, all events matters, we can't know what is happening. ___ The conclusion is, once you have the alarm list with entities(of source scope), you could find their events easily, and as limited queries, there is not a query performance risk. -- 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: [email protected]
