As I was sitting at my desk this morning processing email I was amazed at the number of questions I was getting about basic value propositions of external performance monitoring. I thought maybe it’s not as clear as I suspect it is. So I took off my Engineering hat (which often causes me to be derisive and not understanding of the lack of knowledge) and instead put on my Sales hat (which makes me excited to share information). So here it is, a quick summary of the value of external performance monitoring:
- Alerting – This should always be first. A good portion of the value in performance monitoring comes from being able to evaluate the data collected. But, the most valuable functionality comes from being able to proactively alert yourself as problems are occurring. This allows you to reduce downtime, meet SLAs, and investigate problems as they’re occurring. Central to this is a monitoring frequency that will help accomplish this. If you only monitor once an hour then there is going to be some noticable lag in how quickly you can respond to a problem. If you monitor more frequently (ex: every 5 minutes) then you can react relatively quickly. And even though every 5 minutes is the industry standard, monitoring once every 1 minute can of even more value for your mission critical applications.
- Reporting – This is key. Outside of alerting, all that you have at the end of the data is a set of data and being able to draw conclusions from this data and make educated decisions about the performance of you site/application is key. Your data set needs to be robust because you cannot go back after the fact and collect more data if you feel your data set is too sparse (you can adjust your settings to give you more data in the future but as for the past, that opportunity to collect data has come and gone). Just like alerting, reporting requires a certain interval. For example, you would not want to collect data once an hour and then use that data set to make adjustments to your site.
- Monitoring Client capabilities – This one is a bit more abstract but can be summarized fairly easily. The monitoring client is what performs the monitoring, collects the data, and perceives. Normally such a client is implemented as either an emulation of a browser (a program that makes HTTP requests) or is an actual browser that has a framework around it to automate interactions. The actual browser implementation of this client is the most desired solution because it’s the closest representation of what your end users are experiencing (thus it indirectly makes your data set all the more accurate). The emulated browser is generally better fit for the cost conscious monitoring consumer as it’s only an approximation of what your end user experiences (of the deficiencies of an emulated browser, lack of JavaScript support is probably the most egregious).
So there it is….when you’re shopping around for a monitoring solution you should consider the above three values. You can then take those and sort them in order of importance for the objectives you plan to achieve with monitoring. I generally consider the monitoring client to be the most important factor because it generates the data that is going to be by all other monitoring components (the data collected is more accurate and representative of your users which in turn makes your reports more valuable and makes your alerts more accurate).
