Jamie Wallis

23 September 2019

• Redgate Monitor
• Monitoring Large Estates

Where SQL Server monitoring fits into your tech stack

A technology stack is the set of technologies that are used to build an application. They are essential but will vary in complexity according to the requirements. Do you have a complicated technology stack for your organization’s IT systems? If so, you’re not alone. Gartner estimates that most businesses have IT production systems that require at least 10, often 20, different platforms and tools just to keep the business operational.

Components of the tech stack

Stacks mostly comprise a mixture of owned and hosted (SaaS) tools, installed on the platform that underpins their system. For example, a common Microsoft setup will consist of:

Alongside this, the employees who interact with this setup are likely to require a range of tools that help them manage the various levels of the stack. These tools will have different requirements for each role.

Beyond these core platforms and tools, your business will also use several other pieces of technology, including tools to help build web pages, mange network applications, co-ordinate DevOps processes, create containerized services, and many more.

Stackshare has a library of the stacks from some of the world’s largest companies that you can waste a happy few hours exploring. Here’s an example of the range of tools and platforms Cisco use:

Adding monitoring to your tech stack

Monitoring is an important part of IT management, database and software development, and database management. Whilst very small setups may get by with monitoring each part of the stack separately, for the most part you will want to make use of a monitoring tool that automates most, if not all, of your standard daily processes and checks. A complex application will fail just as comprehensively with a hardware or network fault as with a bug in the application or a problem with a service. To the end user there is no difference.

Very few IT service failures strike like a bolt of lightning from a blue sky. A disk failure will usually be preceded by progressive failure of clusters and warnings from RAID management software. A network fault is likely to have precursors, and SQL Server running out of disk space is a highly predictable event, assuming you’re collecting disk and database growth tracking data.

In the light of this, you need to decide is what sort of monitoring solution you need and who will be the primary user of the tool or tools that deliver it. The first port of call is likely to be a monitoring tool that has plug-ins that allow your operations staff to get a birds-eye view of all the components of your stack so as to be able to deal with routine problems and escalate anything that requires specialized knowledge. A tool like this is ideal for the first responder, but doesn’t directly meet the requirements of other activities within IT.

For IT management, you will most likely want an overall summary view of your platforms, services, applications and databases. They will need a tool that delivers high-level information, mostly around availability and performance that enables them to gauge the resilience and stability of the infrastructure, assess the business impact of changes, and quickly and easily produce reports. This is likely to be the result of aggregating a great deal of low-level data into summary information. Although the data can mostly be collected by a general-purpose monitoring tool, the aggregation and reporting will require a reporting system.

As an IT Manager, you are unlikely to do much deep-dive diagnostic work or want a tool that floods your inbox with irrelevant alerts. You simply need to know the broad picture, and ensure that the right team is aware of, and dealing with, any issues. You will want to know the implication of the various points of potential failure and the steps that have been taken to avoid undue dependency on any such point.

In contrast however, as a database manager, you will, need to be able to see more information on the root cause of trends, concerns, issues and vulnerable aspects of the production environment so you have a better chance of fixing problems rapidly. At some point during a dive-down into issues, a tool that monitors your entire stack just won’t cut it. This is where a specialist server and database monitoring tool can be beneficial.

The hand-off between an operations monitoring tool and dedicated specialist server monitoring should allow the high-level view to indicate where a server has an issue, and the specialist tool to take the diagnosis forward to show exactly what is causing the problem, when it occurred and perhaps even how it can be fixed.

As well as providing a tool that is better suited to the database manager, this form of monitoring can also enable your development teams to better assess the impact of their work, especially during deployments. In other words, your specialist tool should be used to manage not just your production servers, but your development and testing servers too, to ensure compliance and to assess impacts, before they affect your live services.

Monitoring in the Microsoft tech stack

With a Microsoft stack that uses SQL Server or Azure SQL Databases as the relational databases, you will want to use an infrastructure monitoring tool such as Microsoft System Center Operations Manager (SCOM) that will be your IT Manager’s primary reporting tool. They will want to see high-level aggregated views of the data and there are all sorts of native and third-party Reporting Management Packs that slot into SCOM to provide SLA reporting, planning capacity reporting, and more. You would then implement Redgate SQL Monitor for your database management and development work. You can learn more about how these tools work together in this article.

Your SQL Server monitoring solution can go a step further to integrate with other specialist tools in your stack, to improve the DevOps processes within, and across, your teams. For example, you can integrate SQL Monitor with SQL Change Automation and SQL Compare to visualize and analyze the impact of any deployments that have been instigated by those tools. You can also sync it with SQL Backup to get insights into the performance and status of backups performed by this tool. For alerting purposes, you can link SQL Monitor to tools such as Slack and Pagerduty to make sure the right people or teams get the right alerts through their preferred channels.

SQL Monitor can also run alongside IT Service Management Systems (ITSMS) such as ServiceNow via email alerts and Simple Network Management Protocol (SNMP) traps. We’ve recently added API support so you can manage and integrate your alerts through PowerShell, and coming up on our roadmap is support for webhooks so you can integrate SQL Monitor with your preferred ticket management system.

Here is how a tech stack could look at an organization making use of some of these tools and platforms:

Conclusions

When adding a monitoring solution to your tech stack, it is important to try to reconcile the different requirements of your tech teams, to be clear about what you’re trying to solve with it, and who will be the primary user.

Where requirements can’t be met by a basic generic monitoring tool, you will need to ensure you are using supplementary tools that complement each other, so that each user group is able to extract maximum value from them in a way that enhances their projects.

To see how SQL Monitor can fit into your tech stack, download your free 14-day trial.