As the co-founder of Scout (http://scoutapp.com), a hosted server monitoring solution, I wanted to highlight a couple of your points.

Factor #2 (Shifting focus to response time from resource utilization) –

I completely agree, but I’d say the freedom to track any end-user visible metric is key (whether it’s response time, image conversion time, search query time, execution of a background job, etc). It’s important to have a monitoring solution that tracks changes over time and alerts you when the metrics change dramatically.

Factor #3: (Whatever monitoring you put in place needs to be, for the most part, part of your application, and must be installable as a part of your application.) –

While monitoring needs to be part of the application, I don’t think it’s a good solution to define what is being monitored *within* the application (for example, installing monitoring scripts and saving them with an application). It can make the deployment process more complicated, less flexible, and more time-consuming to test monitoring adjustments.

Our approach with Scout is to load the monitoring profile from a single line in a crontab file – no other configuration is required. The monitoring profile for servers can be changed at any time in our scoutapp.com web interface and doesnâ��t require changes to the deployment process. It decouples monitoring from deployment.

Thought you might find the approach interesting (more details, along with a video, is here: http://bit.ly/PJW4o).