Database Reference
In-Depth Information
Sample Design: Application SLA Monitoring
To put a few of the patterns in perspective, let's create a formal design around a system that monitors
application performance service-level agreements (SLAs). In this design, a company already has a
monitoring product that can audit activity in existing SQL Server databases at customer sites. Assume
that the company that makes this monitoring product wants to extend its services by offering a SQL
Azure storage mechanism so it can monitor customers' database SLAs centrally.
Pre-Azure Application Architecture
First, let's look at the existing application-monitoring product. It contains a module that monitors one or
more SQL Servers in an enterprise and stores its results in another database located on the customer's
network.
In this example, Company A has implemented the monitoring service against an existing ERP
product to monitor access security and overall SLA. The monitoring application performs the auditing
based on live activity on the internal SQL Server storing the ERP data. When certain statements take too
long to execute, the monitoring service receives an alert and stores an audit record in the local auditing
database, as shown in Figure 2-15.
Figure 2-15.
Onsite monitoring implementation
On a monthly basis, managers run reports to review the SLAs of the ERP system and can determine
whether the ERP application is still performing according to predefined thresholds as specified in the
ERP vendor contract. So far, the benefits of this implementation include the following:
•
Visibility. The customer has visibility into its internal database's
performance.
SLA management.
Measured SLAs can be used to negotiate contract terms
with the ERP vendor.
However, the customer needs to store the auditing data internally and manage an extra SQL Server
instance; this adds database management overhead, including making sure all security patches
(operating system and database) are up to date. In addition, the local auditing database running on SQL
Server isn't readily accessible to the ERP vendor, so the ERP vendor can't take proactive actions on any
•
