Opserver - several different kinds of cool

A year or so ago I discovered Opserver, a monitoring system/solution built by the guys at Stack Exchange (i.e. those who built Stack Overflow and all its sibling Q&A sites) that can monitor a variety of different things, SQL Server, REDIS, server instances themselves via WMI and more (that I didn't really look at).

A few months ago, just before I left, I finally got round to installing a local instance of Opserver for the DBAs so that they could monitor the Dev & Test SQL Server instances, primarily as a precursor to getting it rolled out into production for monitoring but also so that we could use it in a non-production environment to look for areas for improvment. After having installed and configured it (which is very, very, very easy!), we took a look at some of the SQL Server metrics for the test server and immediately found something to improve.

The most frequently run query against the Test infrastructure SQL Server instance was one where the result of the query should've been cached. Yes, caching is hard. If memory serves, I think the result wasn't being cached because we were generating inconsistent cache keys. Yes, naming is hard. It was only a tiny query, with a tiny resultset, but it was being executed more times than any other query in the system - in production this meant it was being run several million times a day, instead of several hundred. Finding that (and there was more!) made the time spent installing Opserver pay for itself several times over.

I also showed it to a contract DBA resource we had in for a SQL Server estate review - he didn't know it existed and has now added it to his "toolbox" as it covers a sufficiently large area of the functionality of a paid-for solution (whose name escapes me) that he recommended to people previously.

Try it - you mightwill like it!