[bugfix] resolve firing alerts when a monitor is deleted (#2402) by markjoin123 · Pull Request #4478 · apache/hertzbeat · GitHub
Skip to content

[bugfix] resolve firing alerts when a monitor is deleted (#2402) - #4478

Open
markjoin123 wants to merge 1 commit into
apache:masterfrom
markjoin123:cursor/resolve-alerts-on-monitor-delete-f5b2
Open

markjoin123 wants to merge 1 commit into
apache:masterfrom
markjoin123:cursor/resolve-alerts-on-monitor-delete-f5b2

Conversation

@markjoin123

Copy link
Copy Markdown

What's changed?

Fixes #2402.

Deleting a monitor cancels its collection job. A firing alert for that monitor can never receive the metrics sample that would recover it, so group convergence keeps resending the notification. The content shows only the raw monitor id because the monitor row is already gone.

MonitorDeletedEvent previously only cleaned push-gateway state. Real-time alerts already carry hertzbeat.monitor.id, so after the delete transaction commits this change:

  • removes that monitor's pending and firing alerts from the in-memory alert cache
  • drops those alerts from the group-notification cache without sending another notice
  • persists the matching firing single alerts as resolved, and resolves a group alert when every member belonged to the deleted monitor
  • ignores late metrics for that monitor for 30 minutes so an in-flight sample cannot open a new firing alert

No recovery notification is sent. The monitor no longer exists, and another notice would repeat the orphaned alert.

Checklist

  • I have read the Contributing Guide
  • I have written the necessary doc or comment.
  • I have added the necessary unit tests and all cases have passed.

Add or update API

  • I have added the necessary e2e tests and all cases have passed.

Validation

  • ./mvnw -pl hertzbeat-alerter -am install -DskipTests — checkstyle reports 0 violations
  • ./mvnw -pl hertzbeat-alerter test — Tests run: 709, Failures: 0, Errors: 0, Skipped: 0

AI assistance: implementation draft.
Human validation: checkstyle and the full hertzbeat-alerter unit-test run above.
Risk notes: alerts created before hertzbeat.monitor.id was stored cannot be matched by monitor id. A sample that arrives more than 30 minutes after deletion is no longer suppressed.

Deleting a monitor cancels collection, so a firing alert can never recover
and group convergence keeps resending it. Close those alerts on delete
without emitting another notification.

Co-authored-by: markxu <markjoin123@users.noreply.github.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] <Duplicate alarms exist for deleted monitoring resources>

2 participants