Watch Basics

The Rio Watch framework provides mechanisms to collect and analyze programmer defined metrics defined in a distributed application. This framework may be used to instrument services developed under the Rio Architecture and to monitor performance and other measurable aspects of distributed operational strings of execution using this architecture.

The approach outlined in this document provides the basis for recording a measurement of a metric. Recording can be done either locally within a JVM or remotely across different JVM's. Depending on the type of metric being observed (watched), the type of watch differs:

• A GaugeWatch provides a mechanism to record values that can go up and down, and can be positive or negative.
• A CounterWatch provides a mechanism to count a monotonically increasing non-negative value of an arbitrary occurrence of something over time.
• A StopWatch is a Watch for capturing elapsed time.

Each of these watches extend from ThresholdWatch, which contains ThresholdValues, which in turn can have SLAs attached to them providing specific SLAPolicyHandlers approaches

Watches record Calculable objects that contain the value of the metric being observed and the time when the metric was captured. These objects are stored in a WatchDataSource. The WatchDataSource can be transient or persistent, and provides a repository for given watch instance Calculables.

While the Watch framework is generic in that it can collect any kind of metric, a common use will be to measure application response times. It is useful to analyze this type of measurement to understand the Watchable Framework.

SLA Fundamentals

Using the policy mechanisms available in Rio, services can have SLAs attached to them, ensuring operational criteria is met. The dynamic service's operational behavior can be monitored and dynamically scale it's environment up & down based on declarative attributes. Generically speaking, we think of these as Behavioral Policies.

Rio provides support to observe and watch system and application defined metrics. The approach is based on a sensor-effector pattern. Data is observed from applications, OS, hardware, etc ... and measured against declared thresholds.

SLA Policy Handlers

Policy enforcement can happen locally, distributed or hierarchically. Policy enforcement is handled by SLA Policy Handlers. SLA Policy Handlers provide if-then-else logic required to deal with the problem set they know about, are associated to Watches, and are notified of out-of-bound conditions. Rio provides three different SLA Policy Handlers:

• SLAPolicyHandler
  A SLAPolicyHandler handles thresholds for a ThresholdWatch, registering to a ThresholdManager. If a threshold is crossed (breached or cleared), the SLAPolicyHandler will fire a SLAThresholdEvent. The SLAPolicyHandler should be extended to provide logic on how to process specific policy (if-then-else logic) on how to manage SLA Thresholds produced by ThresholdWatch instantiations.
• ScalingPolicyHandler
  The ScalingPolicyHandler extends the SLAPolicyHandler, and will increment and optionally decrement instances of the ServiceBean it is associated to based on limits set for the SLA. Service allocation happens based on declared service requirements.
• RelocationPolicyHandler
  The Relocation Policy Handler also extends the SLAPolicyHandler, and based on configured attributes will work with the Provision Monitor to relocate the service instance to a more appropriate compute resource based on the service's declared attributes. Relocation does not directly deal with service state, service state is managed by the service itself.

Next