[FEATURE] Query and alert filtering: ignore lists, alert muting, database exclusions

[erikdarlingdata]

Overview

Users need the ability to filter out noise from monitoring and alerting — specific queries, databases, or alert patterns they don't care about. This is especially important for Azure SQL DB where system queries in master (e.g., sys.fn_MSxe_read_event_stream) generate recurring alerts the user can't control.

Ref: #226

Scope (layered, increasing complexity)

1. Database exclusion list (per-connection setting)

• Add a list of databases to exclude from alerting (and optionally collection)
• Default exclusions for Azure SQL DB connections: master, msdb
• Simple to implement: filter in the alert evaluation logic

2. Alert muting

• Allow users to mute/dismiss specific recurring alerts
• Pattern-based: "mute all alerts matching this query text / database / wait type"
• Instance-based: "mute this specific alert"
• Muted alerts still collected, just suppressed from the UI and notifications
• Persisted across app restarts

3. Query ignore list (global or per-connection)

• Filter queries out of collection results and/or display
• Match criteria (any combination):
  • Database name
  • Query text pattern (LIKE / contains)
  • Query hash / plan hash
  • SQL handle / plan handle
  • Login name
  • Program name / host name
• Applies to: active queries, query stats, procedure stats, query store, blocking, alerts
• UI: settings page with add/edit/remove, import/export

Design considerations

• Filtering at alert evaluation time is simplest and lowest risk
• Filtering at collection time reduces storage but loses data permanently
• Filtering at display time preserves data but still generates noise in trends/charts
• Probably want all three layers eventually, with alert filtering first

Priority

Alert muting and database exclusions are high value / low effort. Full query ignore lists are a larger effort best planned carefully.

[erikdarlingdata]

Design Plan — Query & Alert Filtering

This is a layered plan, broken into three phases of increasing complexity. Each phase is independently shippable. Looking for feedback on priorities and approach before implementation.

---

Phase 1: Database Exclusion List (per-server)

What: Let users exclude databases from alerting and collection. Most common request — Azure SQL DB users get constant noise from master/msdb system queries they can't control.

Where filtering happens:

• Lite: Add ExcludedDatabases string array to ServerConnection model. Filter at collection time — excluded databases never reach DuckDB. Configured in the existing Edit Server dialog.
• Dashboard: Add config.excluded_databases table (per-server, server_name + database_name). Filter at alert evaluation time — data still collected for historical review, but no alerts fire. Configured in a new Settings section or per-server dialog.

Default exclusions for Azure connections: master, msdb (auto-populated when DatabaseName is set, user can remove).

Affected collectors (Lite):

• Query snapshots (dm_exec_requests has database_id)
• Blocking chains (has database context)
• Query stats, procedure stats (have database_id)

Open question: Should Dashboard also filter at collection time (skip writing to PerformanceMonitor DB), or only suppress alerts? Collection-time filtering loses data permanently but reduces storage. Alert-time filtering preserves data for forensics.

---

Phase 2: Alert Muting Rules

What: Persistent rules that suppress specific recurring alerts. Three flavors:

1. "Mute this" (instance) — Right-click an alert in Alert History → "Mute alerts like this". Auto-creates a rule matching the alert's metric + server.
2. Pattern rules — User-defined rules matching combinations of: metric name, server, database, query text (contains/regex), wait type.
3. Time-based muting — "Mute for 1 hour / until tomorrow / permanently". Useful for maintenance windows.

Storage:

• Lite: New DuckDB table config_alert_mute_rules (id, server_pattern, metric_pattern, database_pattern, query_pattern, expires_at, created_at, reason)
• Dashboard: JSON file alert_mute_rules.json (same structure)

Evaluation: Checked in EvaluateAlertConditionsAsync() (Dashboard) and alert recording (Lite) — muted alerts are still logged with a muted = TRUE flag, just suppressed from UI/notifications/email.

UI:

• Right-click context menu on alert rows ("Mute alerts like this...")
• Settings → Alert Rules page showing active rules with enable/disable/delete
• Badge on muted alerts in history: "🔇 Muted" indicator

Open question: How granular should pattern matching be? Simple string contains, or full regex? Regex is powerful but hard for most users. A middle ground: contains, starts with, equals, not equals — reusing the existing FilterOperator enum.

---

Phase 3: Query Ignore List

What: Filter specific queries out of collection, display, or both. Most complex phase — affects multiple tabs and collectors.

Match criteria (any combination, AND logic):

• Database name
• Login name / program name / host name
• Query text (contains)
• Wait type

Three filtering layers (user chooses per rule):

Layer	Data preserved?	Alerts fire?	Shows in grids?	Best for
Collection	❌	❌	❌	Known-noisy system queries
Alert	✅	❌	✅	Queries you want to see but not be alerted on
Display	✅	✅	❌	Temporary focus (hide clutter while investigating)

Storage: query_filter_rules table/JSON with: id, name, match criteria fields, filter_layer (collection/alert/display), is_enabled, per_server_id (null = global), created_at.

UI: Settings → Query Filters page with add/edit/delete. Import/export for sharing between instances.

Open questions:

1. Should display-layer filters be session-only (lost on restart) or persisted? Session-only is simpler and avoids "why can't I see my queries" confusion.
2. Should there be a quick "ignore this query" right-click option on any query row, similar to alert muting?
3. Is query hash / plan hash matching needed, or is text + database + login sufficient for most cases?

---

What's NOT in scope

• Per-server alert thresholds (different CPU% warning per server) — separate feature, different UI
• Scheduled muting (maintenance windows with calendar UI) — could come later as Phase 2.5
• Machine learning / anomaly-based filtering — out of scope entirely

---

Feedback wanted

1. Phase priority: Is this the right order? Should alert muting come before database exclusions?
2. Collection vs alert filtering: For Dashboard, should database exclusions skip data collection entirely, or just suppress alerts?
3. UI placement: Per-server settings in Edit Server dialog, or a centralized Filtering/Rules page?
4. Phase 3 complexity: Is the three-layer model (collection/alert/display) worth the complexity, or should we just do collection + display?
5. Anything missing? What filtering scenarios aren't covered here?

[parrotdba]

Phase 1 Open Question - Only suppress alerts, keep collecting all data for forensics

Phase 2 Open Question - The middle ground options would be great

Phase 3 Open Questions -

1. I would choose persisted - a visual indicator that results are currently being filtered would help prevent the "oh I forgot I filtered those out" scenarios
2. Initial reaction is "yes that would be cool" but then realizing that would kinda be black-box-ey - how do I know how what's being suppressed? By spid? Query Text? By database/user/a combination of the above? The not knowing would bother me and I would worry about context changes suppressing alerts I don't want suppressed. So maybe?
3. Not needed for myself

Phase 4 Feedback Questions -

1. Yes - I'm currently testing on a couple servers and the alerts on queries with waitfors are a bit extreme in my environment 😲 Native examples - the AlwaysOn_health extended event runs as long as the server's been up, and service broker queues both use waitfors
2. Just suppress alerts - I would still want the data collected
3. Centralized would be more convenient, as long as alerts could be toggled off and on per server
4. The alert piece is the super important piece for me. I'm the type I still want the data collected and available to pour over, I just don't necessarily want alerts on some things. But if there's an issue, I want all the data available
5. Noting I can think of? To be as simple as possible, just filtering out specific query texts from alerts would be amazing. Well the whole thing is already amazing, but this would make it more amazing-er 😄

[erikdarlingdata]

@parrotdba — the AlwaysOn health / WAITFOR alert noise should be resolved in v2.1.0. PR #362 (by @HannahVernon) added exclusions for sp_server_diagnostics and WAITFOR wait types from long-running query alerts. Give it a try and let us know if it's still noisy.

Phase 1 + 2 are still on the roadmap for a future release.

[parrotdba]

@erikdarlingdata Yep much better in the new version THANK YOU 😁

[erikdarlingdata]

@parrotdba great to hear! We'll keep working on the other stuff too.

[HannahVernon]

@erikdarlingdata - I'm working on the Alert Muting feature.