In my mind it isn't a one OR the other proposition. If you have things that you want to monitor often it makes sense to have the instance gather and store that information for later pickup. For most things a daily pickup is fine. But I would expressly limit what I put on each instance because updates are much harder in this model since you have to touch each instance. I prefer the central command and control structure for most things. Especially for configuration management. If you are going to deploy things out to each instance I would strive to make the code as simple as possible so that the chances of changes to that code are minimized. The more complex it is the more likely you will have problems.

with all that said I use and like the Redgate SQL Monitor software. But it doesn't provide for a lot of the details I want and it makes sense for it not to. I want to capture and store many of the options about a database, options that have little performance impact, but I want to know when they change. Same for SQL Agent jobs, I want to know when these change and how. SQL Monitor does a great job of telling me they failed, or that their run duration was unusual but not that the job changed today.

And they build vs. buy is going to often end with Buy and build to fill in the voids not covered. The solution I have been working on doesn't provide real-time monitoring, it is mostly configuration management and logging. There is some overlap with SQL Monitor on database size tracking but much less granular..

CEWII