Reference Guide
Table Of Contents
- 1 Introduction
- 2 Establishing Your Test and Development Environments
- 3 Developing Applications
- Introduction
- Authentication
- REST API
- Audit Logging
- Alert Logging
- Configuration
- High Availability
- OpenFlow
- Metrics Framework
- GUI
- SKI Framework - Overview
- SKI Framework - Navigation Tree
- SKI Framework - Hash Navigation
- SKI Framework - View Life-Cycle
- SKI Framework - Live Reference Application
- UI Extension
- Introduction
- Controller Teaming
- Distributed Coordination Service
- Persistence
- Backup and Restore
- Device Driver Framework
- 4 Application Security
- 5 Including Debian Packages with Applications
- 6 Sample Application
- Application Description
- Creating Application Development Workspace
- Application Generator (Automatic Workspace Creation)
- Creating Eclipse Projects
- Updating Project Dependencies
- Building the Application
- Installing the Application
- Application Code
- 7 Testing Applications
- 8 Built-In Applications
- Appendix A
- Appendix B
- Bibliography
diagram, should demand relatively little effort from a developer beyond creating and updating the
metrics they wish to utilize.
Figure 19 Metrics Architecture
Essentially a component or application must contact the MetricService to create a new
TimeStampedMetric on their behalf; they will be returned a reference to the resulting (new)
TimeStampedMetric object. The developer can then manipulate the returned TimeStampedMetric
object as appropriate for their own needs, updating its value at their own cadence, on a regular
or irregular basis, to reflect changes in whatever is being measured.
Behind the scenes, the MetricService API is backed by a MetricManagerComponent OSGi
component. This component delegates almost all of its work to a MetricManager singleton, which
(conceptually) contains a centralized Collection of the TimeStampedMetric references doled out at
the request of other components and applications. This Collection of TimeStampedMetric
references allows the metering framework to process the TimeStampedMetrics en masse,
irrespective of which application or component requested them, in a fashion that is completely
decoupled from the requesting application's or component's use of the TimeStampedMetrics.
The most essential processing done by the metering framework is to periodically persist
TimeStampedMetric values to disk, and to expose "live" TimeStampedMetric values through JMX.
Other processing is also done, such as aging out old TimeStampedMetric values. Decoupled from
this ongoing persistence of TimeStampedMetric values that are still being used, values that have
already been persisted from TimeStampedMetrics over time may be read via the REST API and
exported for further analysis or processing outside the controller
TimeStampedMetric Types
There are seven types of TimeStampedMetric. They are listed below, with an example of how each
type might be used.
•
TimeStampedCounter
A cumulative measurement that is incremented or decremented when some event occurs.
Example application: the number of OpenFlow devices discovered by the controller.
•
TimeStampedGauge
47