Feature request: Top level defaults

[chadbaldwin]

For larger configurations, it can be hard to keep source connection configurations in check. And it can become a pain if you have a lot of custom settings.

I think it would be nice to have the ability to set some sort of top level defaults for both connections as well as collections.

For example, I currently have 95 instances that I'm monitoring. I decided to change the "Plan Collection Duration Threshold" to a lower value. Having to do this for 95 instances is a bit of a pain. I actually end up using a keyboard macro to do it 😂

I have similar issues with collection schedules. I've been tweaking collection schedules lately so that certain collections kick off before or after other external processes run that might impact that collection. For example, we have a nightly data archiving process, so I want the TableSize snapshot to run after that completes. However, having to open 95 collections prompts to update the cron schedule is a pain. (typically I use PowerShell to do this now, but that's still a pain).

Maybe some sort of "master" source connection that serves as the top level default? And it could work as a coalesce, if the value isn't specified in that top level source connection, then the current service default is used.

[DavidWiseman]

For schedules, there is a service level configuration on the Options tab. Schedules if defined at instance level take precedence, then the service level that you configure on the Options tab, then the defaults coded in the app. If you have different groups of servers that require different schedules, it might be easier to split into seperate services and manage the service level schedule.

As it's a json file, powershell is an option as you mentioned or you might just be able to use a simple find/replace in some cases to change settings in bulk.

Some easier way to do bulk updates would be useful though or service level defaults. Maybe a context menu on the grid where you can right click and bulk update to this value or something.

[chadbaldwin]

I don't know how this whole time I completely missed that service level schedule config. That would have saved me so much time 😂 You should see my current config file, it's an absolute monster because my PowerShell script is setting a custom config for all instances for pretty much all schedules (I don't want any to run at service start).

I also have a second agent running which only does schema snapshots, and that config is also a monster because I disable every collection on every instance.

Thanks for pointing that out to me, that will help me clean up my configs quite a bit.

[DavidWiseman]

It was useful to have collections run on service start as that was the only way to trigger collections to run on demand (restarting the service). It's still useful to a degree when adding new instances. With the Messaging feature, you can trigger collections to run on demand from the GUI, so there is less need to run on service start.