Since the introduction of IT alerting systems a couple of decades ago, everyone followed a very simple template. You’d first define the metricor condition that the alerting system observes, followed by the response or action that the system should perform when the specified value of the metric is exceeded (sometimes called a threshold or trigger). When triggered, alert responses might include the execution of a program or the notification to a user via e-mail, Short Message Service (SMS), or some other method.
I’ve just written a new white paper, called SQL SERVER, SHAREPOINT & WINDOWS ALERTS: A New Take on Alerting. I’ve spent decades of my career implementing alerting systems within the IT enterprise and almost as many years helping to develop some of the most popular alerting systems in the marketplace. It is my hope that this white paper will help inform you to the limitations and risks found in most alerting systems and provide strategies for combating those limitations. In this white paper, we use the basic alerting system included with SQL Server Management Studio (SSMS) to illustrate and compare how the majority of commercial alerting systems behave and how SQL Sentry’s new alerting system, introduced in v8, is far superior. Let me be clear – this is about how the products which I have a hand in creating handle many of the most common issues found in other alerting systems. It is not an unbiased report.
On the other hand, if you’re using and committed to some other alerting system, this white paper can still be useful to you. How? Well, as the old adage goes, “The first step to improvement is admitting there’s a problem.” So this white paper can definitely draw your attention to problems you might be unaware of but are experiencing and, in turn, may provide ideas for preventative measures.
What ARE those Most Common Failures and Shortcomings in Windows, SharePoint and SQL Server Alerting Systems?
When a team puts an alerting system in place, the IT organizations is able to provide better quality of customer support by forewarning staff of problems, ensure higher uptime, and often enabling staff to fix an issue even before the end-users are aware of a problem in their application. Powerful stuff! Unfortunately, most alerting systems have a lot of problems and issues. The most common issues, which I discussed in detail in the white paper include:
- Inability to choose the appropriate response for a given alert, whether for a SQL Server alert, a SharePoint alert, or a Windows alert.
- Limited conditions and thresholds for alerts.
- Noisy alerts, because they do not support customized conditions or because they do not have a context for “normal” discerned from an analysis of baseline conditions.
- Limited or no ability to analyze the cause and effect of an alert, at the SQL Server Agent job level, at the overall SQL Server process level, or at the Windows Server process level.
- Limited or no ability to see overall system performance at the time of an alert, including other components of the Microsoft stack where SQL Server is running or across many servers in the production environment.
- No ability to respond conditionally to alerts.
- Inability to analyze alert trends, either individually for each alert event or in aggregate across all occurrences of the event over time.
So whether you’re currently using a Windows, SharePoint, or SQL Server alerting system that you’re very happy with or you’re considering acquiring one, it’s important to be aware of the potential limitations of that alerting system and then develop strategies to shore up those weaknesses.
The white paper is available online.
I look forward to hearing your feedback! Best regards,
-Kevin
