You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Without pagination of the APIs, the getAlertGroups and getAlerts can cause a significant performance impact on the server
After discussed in proposal, we get an agreement on create a brand new API to return only alert group information.
This proposal will discuss the API spec of the paginated version of getAlertGroups and getAlerts
getAlertGroupsInfo
URL query parameters:
maxResults Integer. The maximum number of alert groups to return in one getAlertGroupsInfo operation. The range is 1–1000. Optional
nextToken String. The token for the next set of items to return. (You received this token from a previous call.). Optional
filter An array of strings. A list of matchers to filter alert group by. Optional
receiver String. A regular expression matching receivers to filter alerts by. Optional
For current data structure, one route can not be unique identified by receiver name.
However in order to search the alerts by alert group we need a fingerprint to identify the referenced alert group. The finger print to unique identify the alerting group should be group labels + route info.
We proposed to generate a unique identifier to each route as it is created
Add group information for each alert in the response of getAlerts API
It will be a better user experience if we can link the alerts back to the alert groups.
We proposed to add the groups info for each alert to the response of getAlerts API
The text was updated successfully, but these errors were encountered:
Background
Without pagination of the APIs, the getAlertGroups and getAlerts can cause a significant performance impact on the server
After discussed in proposal, we get an agreement on create a brand new API to return only alert group information.
This proposal will discuss the API spec of the paginated version of getAlertGroups and getAlerts
getAlertGroupsInfo
getAlerts
other consideration
Add UUID for each route
For current data structure, one route can not be unique identified by receiver name.
However in order to search the alerts by alert group we need a fingerprint to identify the referenced alert group. The finger print to unique identify the alerting group should be group labels + route info.
We proposed to generate a unique identifier to each route as it is created
Add group information for each alert in the response of getAlerts API
It will be a better user experience if we can link the alerts back to the alert groups.
We proposed to add the groups info for each alert to the response of getAlerts API
The text was updated successfully, but these errors were encountered: