[FEATURE] Feature Request: Named Collection Presets ("One-Click Profile Switching")

[gdonufrio]

Which component(s) does this affect?

• Full Dashboard
• Lite
• SQL collection scripts
• Installer
• Documentation

Problem Statement

Summary
First off — a friend of mine saw PerformanceMonitor and immediately asked "can I switch everything to turbo mode with one click?". I told him to open an issue. So here we are. I'm a little sorry. He is not.
PerformanceMonitor already allows per-collector interval configuration — and the global config approach makes total sense. The only thing missing is a way to shift all intervals together in one gesture, instead of adjusting 20 collectors one by one.
If this doesn't fit the vision for the tool, absolutely no worries — just closing it is fine. But in case it sparks something useful, here's the idea.

The Problem
The global config is great for "set it and forget it". The friction shows up in two specific moments:

Incident response: you want maximum sampling resolution right now, across everything, fast — then back to normal when it's over or i have a server with too pressure and I want a preset very light.
Constrained environments: deploying on a smaller Azure SKU and you want to dial everything down in one shot without hunting through 20 sliders.

Neither case is hard to do manually. It's just tedious, and under incident pressure "tedious" often means "I only changed 6 of the 20 and now my data is inconsistent".

Proposed Solution

Proposed Solution: Named Presets

Three built-in presets that set all collector intervals simultaneously:

Preset | Description | Typical use case -- | -- | -- Low-Impact | Long intervals, reduced pressure | Busy OLTP, HADR secondaries, cost-sensitive Azure SKUs Balanced | Current defaults (no change for existing users) | Standard production monitoring Aggressive | Short intervals, maximum resolution | Incident investigation, dev/staging

A fourth mode, Custom, means "user has manually edited one or more intervals" — the current behavior, preserved exactly as-is.

Use Case

Use Cases

1. Incident response

Something's on fire. You want dm_exec_requests and waiting_tasks snapshotting every 15 seconds, not every minute. Right now you either live with 1-minute gaps or spend 3 minutes clicking through sliders while the incident is actively happening. Switching to Aggressive in one click and back to Balanced when it's over is the entire ask.

2. Low-spec or cost-sensitive environments

A 2-vCore Azure SQL Flexible Server, a client who's a bit squeamish about monitoring overhead, a secondary you're keeping an eye on but not actively investigating. Low-Impact lets you say "yes, it's being monitored" without the collector pressure showing up in your own wait stats.

3. Onboarding

New users see 20 collectors all at 1 min and have no reference for whether that's too much or too little for their workload. A named preset communicates intent, not just a number. "Balanced is fine for most production servers" is a more useful signal than a blank interval field.

Alternatives Considered

Do nothing
Honestly fine. The manual config works, it's just tedious. If the complexity isn't worth it, closing this is a perfectly valid answer.

Additional Context

Proposed Intervals

Collector | Low-Impact | Balanced | Aggressive -- | -- | -- | -- query_snapshots | 5 min | 1 min | 15 s blocked_process_report | 2 min | 1 min | 15 s waiting_tasks | 5 min | 1 min | 15 s wait_stats | 5 min | 1 min | 30 s query_stats | 10 min | 1 min | 30 s procedure_stats | 10 min | 1 min | 30 s cpu_utilization | 5 min | 1 min | 30 s file_io_stats | 10 min | 1 min | 60 s memory_stats | 10 min | 1 min | 60 s memory_grant_stats | 5 min | 1 min | 15 s tempdb_stats | 5 min | 1 min | 60 s perfmon_stats | 5 min | 1 min | 30 s deadlocks | 5 min | 1 min | 30 s memory_clerks | 30 min | 5 min | 2 min query_store | 30 min | 5 min | 2 min running_jobs | 30 min | 5 min | 2 min

On-connect collectors (server_config, database_config, database_scoped_config, trace_flags) stay untouched.

If this doesn't fit the roadmap, closing it is totally fine — no pressure. Thanks for reading.

[erikdarlingdata]

This is actually a great idea. I'll work on this.

[erikdarlingdata]

Closed by PR #463 (merged to dev)