-
Notifications
You must be signed in to change notification settings - Fork 11.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alerting: Add notification policies preview in alert creation #68839
Alerting: Add notification policies preview in alert creation #68839
Conversation
eb336c9
to
c7d7bc0
Compare
Co-authored-by: Konrad Lalik <konrad.lalik@grafana.com>
…the code more clean
… from parent as we do with undefined
… policy matchers to match potential instances" This reverts commit ee73ae9.
8e88d0e
to
8c0b6c3
Compare
💯 good catch @VikaCep ! Commit pushed! prev-mess.mp4 |
public/app/features/alerting/unified/__snapshots__/PanelAlertTabContent.test.tsx.snap
Show resolved
Hide resolved
const { matchInstancesToRoute } = useRouteGroupsMatcher(); | ||
|
||
// to create the list of matching contact points we need to first get the rootRoute | ||
const { rootRoute, receivers } = useMemo((): { rootRoute?: RouteWithID; receivers: Receiver[] } => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can remove the necessity to type the return value here by simply explicitly setting rootRoute
to undefined
when we check for the AMConfig
@@ -29,6 +29,8 @@ import { getAllDataSources } from './utils/config'; | |||
import { ALERTMANAGER_NAME_QUERY_KEY } from './utils/constants'; | |||
import { DataSourceType, GRAFANA_RULES_SOURCE_NAME } from './utils/datasource'; | |||
|
|||
import 'core-js/stable/structured-clone'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not use cloneDeep
from lodash
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's mainly a matter of preference for me to use built-in functions instead of external ones. Unfortunately, we use a quite old Node version, so a polyfill is needed in tests
...p/features/alerting/unified/components/rule-editor/notificaton-preview/NotificationRoute.tsx
Show resolved
Hide resolved
public/app/features/alerting/unified/components/rule-editor/NotificationsStep.tsx
Outdated
Show resolved
Hide resolved
}: NotificationRouteProps) { | ||
const styles = useStyles2(getStyles); | ||
const [expandRoute, setExpandRoute] = useToggle(false); | ||
const GREY_COLOR_INDEX = 9; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
non-blocking: not a big fan of this approach since the color index might be updated at some point in the future, but not blocking for now.
Maybe we should roll our own tag component, one that supports a custom function to define the color and allow manual color overrides?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a TODO
comment for this one
...p/features/alerting/unified/components/rule-editor/notificaton-preview/NotificationRoute.tsx
Outdated
Show resolved
Hide resolved
...p/features/alerting/unified/components/rule-editor/notificaton-preview/NotificationRoute.tsx
Outdated
Show resolved
Hide resolved
1187e38
to
261b12f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First round of review, looks awesome! Just a few comments/questions 💬
public/app/features/alerting/unified/components/rule-editor/NotificationsStep.tsx
Outdated
Show resolved
Hide resolved
...features/alerting/unified/components/rule-editor/notificaton-preview/NotificationPreview.tsx
Outdated
Show resolved
Hide resolved
...features/alerting/unified/components/rule-editor/notificaton-preview/NotificationPreview.tsx
Outdated
Show resolved
Hide resolved
...features/alerting/unified/components/rule-editor/notificaton-preview/NotificationPreview.tsx
Show resolved
Hide resolved
...features/alerting/unified/components/rule-editor/notificaton-preview/NotificationPreview.tsx
Outdated
Show resolved
Hide resolved
...features/alerting/unified/components/rule-editor/notificaton-preview/NotificationPreview.tsx
Outdated
Show resolved
Hide resolved
...fied/components/rule-editor/notificaton-preview/useAlertmanagerNotificationRoutingPreview.ts
Outdated
Show resolved
Hide resolved
Hey there! am seeing the UI text not exactly matching this doc - can you cross-check and update? thanks! https://docs.google.com/document/d/1drJhkJ0O7fvQeOO8_c6V0FAu3_3mBtkFZuJJbbOHJ-o/edit#heading=h.neepxy20wlig |
c74d226
to
ba150ab
Compare
Thank you @brendamuir ! I've just updated the text following the doc: ![]() ![]() |
9734fe7
to
b008cac
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM no blockers
* Add notification policies preview in alert rule form Co-authored-by: Konrad Lalik <konrad.lalik@grafana.com> * Refactor using new useGetPotentialInstances hook and apply some style changes * Add notification policy detail modal * Use backtesting api for simulating potential alert instances * Fix logic to travserse all the children from the root route * Split notification preview by alert manager * Add instance count to matching policy header and fix some styles * Move some logic to a new hook useGetAlertManagersSourceNames to make the code more clean * Fix some tests * Add initial test for NotificationPreview * Use button to preview potential instances * Add link to contact point details * Add route matching result details * Show AlertManager image in the routing preview list * Add tests setup, add single AM preview test * Handle no matchers and no labels use case * Update some style in collapse component and fix policy path in modal * Update modal styles * Update styles * Update collapse header styling * Normalize tree nodes should happen before findMatchingRoutes call * Fix findMatchingRoutes and findMatchingAlertGroups methods after reabasing * Move instances matching to the web worker code * Fix config fetching for vanilla prometheus AMs * Add tests * Add tests mocks * Fix tests after adding web worker * Display matching labels for each matching alert instance * Add minor css improvements * Revert changes added in Collapse component as we don't use it anymore * Move the route details modal to a separate file * Move NotificationRoute and preview hook into separate files * Fix Alertmanager preview tests * Fix tests * Move matcher code to a separate file, improve matcher mock * Add permissions control for contact point edit view link * Fix from and to for the temporal use of backtesting api * Fix tests, add lazy loading of the preview component Co-authored-by: Sonia Aguilar <soniaaguilarpeiron@gmail.com> * Fix preview test * Add onclick on the header div so it collapse and expands when clicking on it, and update styles to be consistent with the rest of tables * Adapt the code to the new rule testing endpoint definition * Fix tests * small changes after reviewing the final code * compute entire inherited tree before computing the routes map * Throw error in case of not having receiver in routesByIdMap and add test for the use case of inheriting receiver from parent to check UI throws no errors * Add list of labels in the policy route path that produces the policy matchers to match potential instances * Use color determined by the key, in label tags when hovering matchers in the policy tree * Remove labels in modal and handle empty string as receiver to inherit from parent as we do with undefined * Revert "Add list of labels in the policy route path that produces the policy matchers to match potential instances" This reverts commit ee73ae9. * fix inheritance for computeInheritedTree * Fix message shown when preview has not been executed yet * First round for adressing PR review comments * Adress the rest of PR review commments * Update texts and rename id prop in NotificaitonStep to alertUid --------- Co-authored-by: Konrad Lalik <konrad.lalik@grafana.com> Co-authored-by: Gilles De Mey <gilles.de.mey@gmail.com>
* Add notification policies preview in alert rule form Co-authored-by: Konrad Lalik <konrad.lalik@grafana.com> * Refactor using new useGetPotentialInstances hook and apply some style changes * Add notification policy detail modal * Use backtesting api for simulating potential alert instances * Fix logic to travserse all the children from the root route * Split notification preview by alert manager * Add instance count to matching policy header and fix some styles * Move some logic to a new hook useGetAlertManagersSourceNames to make the code more clean * Fix some tests * Add initial test for NotificationPreview * Use button to preview potential instances * Add link to contact point details * Add route matching result details * Show AlertManager image in the routing preview list * Add tests setup, add single AM preview test * Handle no matchers and no labels use case * Update some style in collapse component and fix policy path in modal * Update modal styles * Update styles * Update collapse header styling * Normalize tree nodes should happen before findMatchingRoutes call * Fix findMatchingRoutes and findMatchingAlertGroups methods after reabasing * Move instances matching to the web worker code * Fix config fetching for vanilla prometheus AMs * Add tests * Add tests mocks * Fix tests after adding web worker * Display matching labels for each matching alert instance * Add minor css improvements * Revert changes added in Collapse component as we don't use it anymore * Move the route details modal to a separate file * Move NotificationRoute and preview hook into separate files * Fix Alertmanager preview tests * Fix tests * Move matcher code to a separate file, improve matcher mock * Add permissions control for contact point edit view link * Fix from and to for the temporal use of backtesting api * Fix tests, add lazy loading of the preview component Co-authored-by: Sonia Aguilar <soniaaguilarpeiron@gmail.com> * Fix preview test * Add onclick on the header div so it collapse and expands when clicking on it, and update styles to be consistent with the rest of tables * Adapt the code to the new rule testing endpoint definition * Fix tests * small changes after reviewing the final code * compute entire inherited tree before computing the routes map * Throw error in case of not having receiver in routesByIdMap and add test for the use case of inheriting receiver from parent to check UI throws no errors * Add list of labels in the policy route path that produces the policy matchers to match potential instances * Use color determined by the key, in label tags when hovering matchers in the policy tree * Remove labels in modal and handle empty string as receiver to inherit from parent as we do with undefined * Revert "Add list of labels in the policy route path that produces the policy matchers to match potential instances" This reverts commit ee73ae9. * fix inheritance for computeInheritedTree * Fix message shown when preview has not been executed yet * First round for adressing PR review comments * Adress the rest of PR review commments * Update texts and rename id prop in NotificaitonStep to alertUid --------- Co-authored-by: Konrad Lalik <konrad.lalik@grafana.com> Co-authored-by: Gilles De Mey <gilles.de.mey@gmail.com>
What is this feature?
This feature is about adding the notification policies preview in the alert rule form. That means, showing all the potential instances we could have taking in account:
For getting the the potential instances, we need an endpoint to get this potential labels => we created this issue for solving this problem.
This feature can only be done only for Grafana managed alerts.
Once we have this list of potential alerts, we have to traverse the notification policy tree to apply the algorithm that matches these labels from the list with the notification policies labels. => for this part we need to move some logic to a
webworker
.We also use
Suspense
andlazy loading
for rendering theNotificationPreviewByAlertManager
.Why do we need this feature?
Having this potential alerts from the rule creation context, could be a great help for users understanding which instances will be generated and where will be sent depending on the labels we have.
Who is this feature for?
All users
Which issue(s) does this PR fix?:
Fixes #68098
Special notes for your reviewer:
notification-preview-2.webm
Last three commits make some changes to the details preview:
We removed the labels section as is redundant:
Please check that: