SimonFlexible server monitoring
SimonI'd like to see the ability to define thresholds for response time on the HTTP monitoring service.
For instance, on occasion a site I monitor slows down to 40+ second response time ... something that may as well be considered a failure given the nature of the site. I'd like to be able to define a Green, Yellow and Red on response time with yellow being "warning" for degraded but not failed performance, and red being either failed of so badly degraded it may as well be failed.
Cheers,
Chris.
Re: Threshold definitions
That's a good idea. Simon currently has a fixed timeout of two minutes, after which it is considered a failure. I've thought about making that configurable, but most people seem satisfied with two minutes - so hearing from someone who would prefer a smaller amount is helpful.
Adding the ability to have a warning indicator would add value, too.
Thank you for the suggestions; I've made a note of them for consideration in future releases.
Re: Threshold Definitions
I've been in IT for a number of years and over that time have used a variety of products. One of the better "cheap" products I used was SiteScope. It was bought by Mercury some time ago and has been developed into a larger, more complex monitoring and reporting tool. However, in the first instance, it's simplicity was it's strength and the very simple RAG (red, amber, green) threshold definitions made it great.
The other features that we found useful were the ability to check which HTTP response code was returned, and rather than do a text "change" compare, do a text "match" compare to detect application error messages that where still considered HTTP 200 code returns (i.e. MS SQL error, SSI error).
I think Simon is a great tool, particularly if you want to run something on the Mac and not have to develop too many custom scripts and run the results through something like MRTG. But I think a few simple enhancements like RAG thresholds would be very useful.
Cheers,
Chris.
Re: Threshold Definitions
Thanks again for those suggestions.
Note that you can do a match compare for the HTTP 200 code, by selecting Header in the Smart Change Detection pop-up menu, and entering 200 in the start text (and leave the end text blank). Then if the header doesn't contain 200, it'll be a failure.