December’s a great time to take stock, so I thought it would be worth sharing a roundup of the progress the SQL Monitor development team have made this year. I’m also really excited about what’s coming soon, so will share some insight into our plans for 2017.
A busy 2016
The new Global Overview provides an “at-a-glance” view of your entire SQL Server estate, drawing attention to issues which need your input, and serving as a centralized dashboard.
Servers can be grouped together, and each instance has its own color-coded card, showing its health alongside key metrics. In an office environment, this screen lets everyone see in seconds if something needs to be looked at. The result is a dramatically more useful and more scalable overview of what’s going on.
Entirely new Server Overview pages
The new server overview pages were all about making it faster and easier to diagnose issues. They’re about more than just looking beautiful – from the outset they were built around the idea of providing the context and ‘explorability’ of data you need to understand the true root cause of a problem.
Seeing alert information annotated directly on performance metric graphs enriches them both, and providing all relevant information about a server in a single pane makes it dramatically easier to understand the bigger picture of what’s going on, without needing to jump around between different screens.
This one was a long-time requested capability! SQL Monitor now captures and stores cached execution plans, and lets you either view them directly inside the web UI, or download them for use elsewhere. This is an essential part of troubleshooting badly-performing queries.
The new view is a great way to explore complex plans, making them easy to navigate, as well as picking out various warnings for you.
Alert integration (SNMP, Slack)
Previously, it was possible to have SQL Monitor send you email notifications when alerts were raised. A consistent piece of feedback has been the desire to integrate these alerts with other systems.
We added the ability to send these notifications as messages directly into Slack, or to send SNMP traps. This allows them to be received by other ticket management or monitoring systems like SCOM, with SQL Monitor’s detailed alerts treated as part of a centralized incident escalation process.
We’ve made multiple improvements to the way alerts are raised and configured. Much of this has been around allowing greater configurability of thresholds and better defaults, along with making it easier to silence unwanted alert noise.
There are also structural improvements to some types of alert. For example, the old concept of a “blocked process” alert transformed into a “blocking process” model. This means that if process X blocks a hundred others, then instead of getting a hundred emails saying that a process is blocked, you get a single email telling you about process X, which was causing all the difficulties.
We’ve spent time working on performance and scalability, and have made some sizeable improvements already, including making the server detail pages several times faster to load. There’s a lot more to come in this area too!
This is a new one we’re really excited about, with the beta released towards the end of October, and shipping more completely in December.
Reporting in SQL Monitor allows you to create customized reports, combining the performance metrics available in SQL Monitor’s analysis view with new summary information on things like server uptime, the numbers of alerts being raised, or the disks which are filling up fastest. Reports can be exported to pdf and emailed to you on a schedule.
It’s a great way to gather together information you want to frequently keep an eye on, and to quickly build reports for clients or management – something which can otherwise be pretty slow and boring.
There have been literally thousands of little tweaks, bug fixes, and bits of polish which aren’t worth mentioning here individually, but which combined form part of a greater effort to make SQL Monitor a more delightful tool for you to use. For the sorts of things I mean, grab a coffee and spend an hour or two reading through this year’s release notes!
An exciting 2017
Right now we’ve only worked up our plans for the next six months or so (we’ll be thinking through longer-term plans over the next few months), but this is what we’re expecting to deliver in the first half of the year. I should probably say that this isn’t an exhaustive list of everything we hope to achieve, and that we do adjust our plans a lot based on feedback about our customers’ priorities / other things, so it’s possible that some of this will change.
VM host support
The majority of SQL Monitor users run SQL Server in a virtualized environment. While of course SQL Monitor has always supported these setups, there are many scenarios where some information about the VM layer itself is an important part of understanding performance problems. We’ve already started some work to help with this by providing information about the underlying host machine, which we expect to release and build upon in the first couple of months of 2017.
Performance and scalability
SQL Monitor’s performance is really important, and there are two core areas we plan on devoting significant time to improving. The first is around scalability; that is, the number of SQL Server instances which can be monitored by a SQL Monitor installation. This number depends on a variety of factors, not least of which are how busy those instances are, and the specs of the box SQL Monitor is running on. The second area is around UI performance; that is, how long pages take to load and navigate when you’re exploring data using SQL Monitor.
We made some progress on this in the later part of 2016, and of course performance is always a consideration whatever other work we’re doing, but we think this merits a real concerted effort from the whole team, and investigations have given us some good ideas for improvements which could help. I hope we’ll be able to talk more publicly about our specific performance and scalability goals early in 2017.
Alerting is a huge part of how and why people use SQL Monitor. Key to this is achieving a good signal to noise ratio. The ideal monitoring system will always tell you about things you consider to be important, and will never, ever take up your time with a false alarm.
Back in the real world, no monitoring tool can achieve this perfectly (whether they say otherwise or not!). You as a DBA bring skill, experience, and an understanding of your organization’s distinct needs which means sometimes, you have to make a judgement about how important an alert is and whether it requires action. Most tools, SQL Monitor included, err on the side of giving you too much information rather than too little, because it’s better to have an email you don’t care about than to not discover a major problem.
However, we plan to make some fairly radical improvements to how SQL Monitor lets you configure and filter alerts, so that over time you can train SQL Monitor about which things are and aren’t important to you. We’ll also bake greater intelligence into SQL Monitor, so that out of the box it can do a better job of identifying unusual patterns for you.
We have some pretty cool ideas about ways to make it easier to go from knowing there’s a problem, to understanding the root cause and what you can do about it. I won’t talk more about those here, but expect to see more on this soon!
Have your say
The details of these plans aren’t locked down and we’d love the chance to talk to you to help shape the product’s future. Just email firstname.lastname@example.org.
Thanks for reading, and have a great 2017!
Also in Blog
At Redgate, encouraging personal development in our teams is fundamental to building amazing products.
As well as developing new skills for employees to apply to their current work, personal developm...
Also in Database development
DBAs have a tough job sometimes. When deployments go wrong, they’re the ones everyone looks to. They’re also the ones who have to fix it, which can mean working through the night, the weekend, t...
Also about SQL Monitor
An attacker of SQL Server likes to be able to change the SQL Server configuration settings. In an ideal world, you will have left everything open for the intruder, but generally, every DBA reduces the...