Service Level Monitoring (SLM) checks that an application or service conforms to a contractual Service Level Agreement (SLA). SLM is becoming more and more important as enterprises choose to outsource increasingly large portions of their IT operations to third parties.

Improving cost-effectiveness by outsourcing operations and services to the best value provider has been greatly expanded and supported by the Internet, coupled with cheap, reliable data communications infrastructure and distributed server-based applications.

However, cost is only one part of the equation. Service must meet or exceed expectations, and this requirement leads to the following issues:

• How do you trust outsourcers to deliver the level of service and performance that they have promised?

• How do you enforce the penalties in the outsourcing contract for failing to meet SLA compliance?

• How do you detect such failures?

The SQLstream Solution

The SQLstream solution provides a distributed application infrastructure that collects the service records, often from remote log-files, and processes them by filtering, aggregating, and correlating those records. The result is the information needed to assess the service actually provided and to enforce the agreed SLA.

For example, the service should be able to handle “X” transactions per second during peak periods, or perhaps the application should remain up and running for 99.999% of the time over some suitably long rolling time-window.

The SQLstream solution not only allows for collection of service availability and usage records over time, it also enables detection of missing service availability records over time . A special facility within the SQLstream RAMMS called punctuation can be configured to ensure that timestamp records are generated even when no data flows.

The SQLstream solution proceeds as follows:

• Lower metrics are combined and aggregated into higher-level metrics. For example, metrics for each individual user can be rolled up into an average for all users of an application.

• The SLA is represented as a series of SQL queries against both service availability and higher level metrics data .

• SQLstream compares this stream of results against the SLA contractual requirements, ideally operating continuously in real-time.

• An output stream of SLA failure records is generated.

• Those SLA failure records are then aggregated and submitted against aggregate SLA targets, e.g.,
  "guaranteed conformance with the SLA for application-X 99% of the time”)

• The SQLstream solution then generates email or other alerts for SLA violations, prioritized by the severity and impact of each violation.

Contrast with Conventional SLM solutions

Most SLM solutions today:

• Comprise systems for collecting and processing files, and for aggregating and filtering data in a relational database

• Use database triggers to generate cascading updates when SLA violations occur

• Are unable to scale to large volumes of service availability and service metric records

• Are painful to implement and manage, because managing large numbers of database triggers swiftly becomes a serious problem

  • Trigger-centric applications present difficulties with business rules, because those business rules

    • are not expressed in a declarative language such as SQL

    • are represented in a procedural programming language (stored procedures)

    • are analyzable only by unsnarling a spaghetti-like series of such procedure
      
      
• Scale poorly

• Are error-prone

• Are difficult to maintain and manage.

In contrast, SQLstream's RAMMS allows maximal reuse of the SLA and Service Usage data, enabling an enterprise to incorporate it in any useful recombination with any other dynamic enterprise data.