Overview

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

Types of Watches

Recording a measurement of a metric can be done either locally (within a JVM) or remotely across different JVMs. The type of watch depends on the type of metric being observed (watched):

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

Each of these watches extend from ThresholdWatch (org.jini.rio.watch.ThresholdWatch; see Javadoc), which contains ThresholdValues, which in turn can have SLAs attached to them providing specific SLAPolicyHandlers (org.jini.rio.qos.SLAPolicyHandler; see Javadoc) approaches.

Calculable Objects and the WatchDataSource

Watches record Calculable objects (org.jini.rio.watch.Calculable; see Javadoc), which contain the value of the metric being observed and the time when the metric was captured. These objects are stored in a WatchDataSource (org.jini.rio.watch.WatchDataSource; see Javadoc). The WatchDataSource can be transient or persistent, and provides a repository for the Calculables of a given watch instance.

Using Watches to Measure Application Response Times

While the Watch framework is generic (it can collect any kind of metric), a common use is to measure application response times.

Within an application, a bounded unit of work can be measured for execution time. Because the Service Bean / Service Container model is inherently distributed, this bounded unit of work may be local to one Java Virtual Machine or span multiple Java Virtual Machines.

If endpoints are distributed, a mechanism for clock synchronization is required.

Local Watches

The simplest case is to measure response time within a local Java Virtual Machine. When using the StopWatch class, this class functions as a utility for capturing elapsed execution time. A Calculable record is created and then stored in the WatchDataSource. The getValue method of the Calculable interface returns a double value, which represents the milliseconds of elapsed time for this measurement.

To measure response time metrics in a local JVM, using StopWatch:

1. Create the StopWatch.
   A local instance of a WatchDataSource is created, and the WatchDataSource is associated to the StopWatch.
2. Register the WatchDataSource with the WatchDataSourceRegistry. This allows the WatchDataSource to be discovered by remote clients.
3. Start the timing.
4. Stop the timing.
   Elapsed time is calculated, and a Calculable object is created and added to the WatchDataSource.
5. Repeat Steps 3 and 4 as necessary.
6. Call the getValue method on the Calculable objects to examine the results.

Remote Watches

You can measure response time within a local Java Virtual Machine, but post the results to a remote WatchDataSource. This kind of pattern is useful when the desired outcome is a common collection of metrics from various services or from numerous instances of the same service.

Compared to a local watch, the primary difference is that the WatchDataSource is first located using the Jini Lookup Service. Once located, the constructor for the StopWatch is invoked, passing the reference to the remote WatchDataSource. Once the StopWatch has been created in this way, the rest of the processing steps are the same as the local case.

To measure response time metrics in a local JVM and save result to remote JVM:

1. Find the remote WatchDataSource.
2. Associate the WatchDataSource with the StopWatch.
3. Start the timing.
4. Stop the timing.
   Elapsed time is calculated, a Calculable object is created and added to the remote WatchDataSource.
5. Repeat Steps 3 and 4 as necessary.
6. Examine the results on the remote JVM.