Service Level Monitoring (SLM) concerns checking that an application or service conforms to a pre-agreed Service Level Agreement (SLA).

Financial Services companies, like all service companies, promise to deliver a certain predefined level of service. One example is “all customer trades will be executed within ten seconds of the availability of any buyer at that price and volume.”

There can be steep penalties for failing to live up to agreed SLAs, especially when Financial Services companies provide wholesale services to other companies. These client Financial Services companies often have their own customer SLAs to fulfill, compounding the actual responsibilities, the potential liabilities, and the potential penalties as well. Delays in trades, for example, might lead to a cascade of lost deals and lost money.

SQLstream's Solution

The SQLstream solution for SLA monitoring provides a distributed application infrastructure that collects the service records, often from remote log-files, and processes them, often in real time. By filtering, aggregating, and correlating the data derivable from those records, information corresponding to SLA requirements can be developed and delivered in a manner supporting timely corrective action if needed.

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

The SQLstream RAMMS solution not only allows for collection of service availability and usage records over time, it also allows detection of missing service availability records over time.

The SQLstream Process

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 the data from service availability (and higher level) metrics.

• SQLstream compares this stream of results against the SLA requirements. Ideally, this comparison should be formed continuously in real-time.

• An output stream of SLA failure records is generated.

• SLA failure records are then aggregated and submitted against aggregate SLA targets, such as“we guarantee to be in conformance with the SLA for application X 99% of the time.”

• The SQLstream solution then generates alerts, such as emails, for SLA violations, prioritized by the severity and impact of the violation.

Contrasts with Conventional SLM solutions

Most SLM solutions today:

• Comprise a system for collecting and processing files, and for aggregating and filtering data in relational databases

• 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 due to the problems of managing large numbers of database triggers.

When an application is so heavily involved in database triggers, it has the following difficulties with business rules:

• They are not expressed in a declarative language such as SQL.

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

• They are orchestrated through a series of spaghetti-like database operations.

As a result, such aplications present the following pains and limitations:

• They scale poorly.

• They are error prone.

• They are difficult to maintain and manage.

SQLstream's RAMMS allows maximal reuse of the SLA and Service Usage data and allow those data to be combined with all of the other dynamic data of the enterprise.

RAMMS also scales well and is easy to maintain and manage without interrupting ongoing operations.