Dbz#2314 Alerting support to the Debezium Platform - #486
Conversation
| } | ||
|
|
||
| @Transactional | ||
| public void evaluate(AlertRuleEntity rule, String pipelineId, double value, |
There was a problem hiding this comment.
This method and resolve both open a transaction that blocks until webhooks are sent synchronously, including retries that can block for ~30 seconds. Should we persist the transition and then handle the event/webhook dispatch using a CDI bean or using an @Async / Vert.x event bus?
There was a problem hiding this comment.
Good point. Effectively this is the "dual-write" problem resolvable with the "outbox` pattern :D
For now I think that CDI events is reasonable solution for this uses case.
| case OK -> evaluateOk(conditionMet, forDuration, now); | ||
| case PENDING -> evaluatePending(conditionMet, forDuration, pendingSince, now); | ||
| case FIRING -> evaluateFiring(conditionMet); | ||
| default -> new StateTransition(currentState, StateTransition.Action.NONE, null, null); |
There was a problem hiding this comment.
Should this include an explicit case for RESOLVED, with the default as an error case if new enum values are added but not handled here?
There was a problem hiding this comment.
@Naros This effectively works on the currentStatus so the case the RESOLVED state is never an input state.
So I just removed the RESOLVED state and simplified the switch. Thanks for spotting it.
| @Override | ||
| public AlertRule create(@Valid AlertRule view) { | ||
| validatePanelExists(view.getPanelId()); | ||
| validateForDuration(view.getForDuration()); |
There was a problem hiding this comment.
Should there also be validation for the evaluationWindow that carries the same requirement as the forDuration property? Same question for update method in this class.
| .findFirst() | ||
| .orElse(null); | ||
|
|
||
| if (panel == null) { |
There was a problem hiding this comment.
Does this eventually lead to stale/orphaned AlertStateEntity with no way to resolve them? If so, should we consider resolving them after a configurable no-data grace period?
There was a problem hiding this comment.
Good catch! I'll just auto-resolve in that case and so if a panel is then re-added and the alters is still firing it will be correctly re-evaluated.
Note that for now the panels, are just configured via k8s and not via UI so adding/removing will be less frequent.
…ntities, services, and REST API Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
…Prometheus integration Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
…te transaction to avoid blocking it. Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
Signed-off-by: Fiore Mario Vitale <mvitale@redhat.com>
|
@Naros Could I ask another pass? |
2 participants
Fixes debezium/dbz#2314
Description
This pull request introduces a comprehensive REST API for managing alerting and notification features in the platform conductor module. It adds new resources for alert events, alert rules, and notification channels, along with their associated request and response DTOs. The changes enable CRUD operations, status queries, and notification channel testing, and add the necessary dependencies for email notifications.
The most important changes are:
API Resource Additions:
AlertEventResource,AlertRuleResource, andNotificationChannelResourceclasses, providing REST endpoints for querying alert events and statuses, managing alert rules (CRUD, enable/disable), and managing notification channels (CRUD, test channel) (AlertEventResource.java[1]AlertRuleResource.java[2]NotificationChannelResource.java[3].DTOs for API Communication:
AlertEventResponse,AlertRuleRequest,AlertRuleResponse,AlertStatusResponse,NotificationChannelRequest,NotificationChannelResponse,PagedAlertEventResponse, andTestNotificationResponse, standardizing data exchange formats for the new endpoints [1] [2] [3] [4] [5] [6] [7] [8].Dependency Updates:
quarkus-mailerdependency to the project to support email-based notification channels.PR Checklist
main