Remote awareness is critical to keeping environments healthy. Monitoring should be able to happen no matter where you are located. At the time of writing this (June 2020), it’s likely that you and your team have been working remotely for several months and will keep working remotely for the foreseeable future. Being able to monitor from anywhere is a core part of a successful remote working strategy.
There are many reasons for database professionals to embrace remote monitoring: from the cloud, to non-production environments, to providing fine-grained access to monitoring tools.
Cloud adoption is increasing
Cloud adoption isn’t just increasing, it’s increasing rapidly. The usage of Azure is up 15% compared to 2019 and Azure is the most used cloud platform in the 2020 State of Database Monitoring report. More often than not, your production environment is going to slowly extend into the cloud; lifting an environment into the cloud wholesale is quite rare and error prone. As environments expand into the cloud it’s important to understand performance in both deployments.
Adopting remote monitoring tools can simplify monitoring of the cloud – once you’re monitoring a remote database server it doesn’t matter where the server is. Redgate’s SQL Monitor is able to monitor Azure SQL Database via the same tools used for on-premises SQL Servers. Using SQL Monitor’s groups, monitored systems can be categorized regardless of location – it’s as easy to group by data center as it is to group by purpose.
Non-production environments are more important than ever
If your environment is anything like the ones I’m used to, the non-production environment used to be housed in a server closet down the hall. If there was ever a problem, you could head down to the servers and physically check that the lights were on and take action. In the worst case, someone could open up the local console and confirm what the server was doing. These non-production systems are often used to spot problems before deploying software to customers. With remote working and moves to the cloud, it’s less likely that somebody is able to quickly visit the non-production systems to review system health. How can we make sure that customers are using good software if we can’t visit the server closet anymore?
Monitoring software, like Redgate’s SQL Monitor, makes it simple to monitor non-production servers. Of course, developers need to be able to review the systems to understand any potential problems that might arise. It’s straightforward to create a separate group in SQL Monitor for non-production systems and provide read-only access for developers. Visibility into non-production systems doesn’t need to disappear when nobody is in the office.
Spot errors early
It’s important to spot problems early on. Production environments are rarely well-behaved. Of course, they don’t get that way on their own: code is regularly deployed, configuration settings are changed, and new indexes are created in response to performance problems. 23% of respondents in the State of Database Monitoring survey reported human error as the most frequent source of errors. Even our best attempts at testing can catch error conditions that we never thought of. Monitoring non-production environments is a good start, but errors can make it into production environments.
Database monitoring can alert you to errors as soon as they occur. Configuring the right set of errors for your environment ensures that you’re aware of the most critical errors in your environment as they’re occurring, rather than finding out after the SQL Server has become unresponsive. Alerts aren’t limited to email, though; SQL Monitor provides additional notification options so messages can be sent via Slack, SNMP, or sent to an arbitrary webhook endpoint.
Even if you don’t have notifications configured for alerts, the SQL Monitor dashboard provides a health overview for all monitored SQL Servers. Problematic SQL Servers are highlighted, making it straightforward to drill into your environment and understand how it is operating.
When someone says “access control”, most people immediately think of security. Database security is an important but rarely considered factor in remote monitoring. Via SQL Monitor’s custom metrics, DBAs can create custom auditing at the level they need to track failed logins and other security issues. An uptick in failed logins may provide just enough early warning to prevent a database from being compromised… or just warn about a failed deployment with the wrong password.
Access control is more than keeping people out. Managing a remote environment requires delegating responsibility to other teams; access control can also mean letting the right people in. Developers are a curious lot; providing them with read-only access to your monitoring tools lessens the load on production DBAs. While the DBA team is handling infrastructure-level tasks, developers can focus on improving the performance and stability of their applications. SQL Monitor allows read-only access to an environment – these users can review the environment, but not much else. Recent versions of SQL Monitor have added reporting users. These users have the ability to create new reports and modify existing ones. Developers can customize their dashboards to provide better insights into application performance.
Remote awareness is critical
Here’s what you need to consider to help your teams to work flexibly and remotely:
- Look for an agentless solution with a web-based dashboard. Web-based tools allow access from anywhere and across a wide range of devices.
- Consider tools that allow flexible monitoring: it’s not just DBAs who need to look at systems. Your remote monitoring solution should provide the ability to customize access across different parts of your environment.
- Evaluate how well the solution enables you to monitor hybrid environments; it’s important to be able to monitor on-premises and cloud environments from the same dashboard.
Was this article helpful?
Also in Blog
As a DevOps Advocate at Redgate, I frequently work with Enterprise customers to help them transform their software development process for databases across their entire organization.
I don't do thi...
Also in DevOps
In the first post in this series, I talked about the challenges for the US Government sector when attempting to introduce DevOps. The sector lags behind others such as Financial Services on every meas...