wu-sheng commented on pull request #6888: URL: https://github.com/apache/skywalking/pull/6888#issuecomment-830928908
> > > Shouldn't the current event information be forthe UI to query? > > > My biggest puzzle is where the data will come from if the Event is included in the Alarm Message. > > > > > > The event should be queried by the UI for sure. That is why I asked you to update the query protocol. The event could be from many places, such as k8s re-deployment, agent report, CI/CD system. > > > One final point of confusion: Do all alarm notifiers mean all Call Backs? > > > > > > Yes, once we send this alarm out, we should include events related, HTTP, gRPC, slack, anything we have. > > Yes, I see what you mean. But maybe I didn't make it clear. What I want to make sure is where to get these events and where to put these into the Alarm Message, so that it can be handled by the receiver(eg. http/slack/grpc etc.) of the Alarm. > > Because I saw that when I constructed the Alarm Message, most of the attributes in it were taken directly or indirectly from the configuration file and from the Message Header. OK, if this is about the code structure, I have taken a look. I think you mean, you need to query existing events from database, right? @kezhenxu94 Is EVENT API going to provide an API to do that? As alarm core used to only access the core to add event, rather than reading them. I think due to current implementation, we need to read them first. -- 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]
