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
•
A primary tag (String, no default).
•
A secondary tag (String, no default).
•
A description (String, no default).
•
The summary interval in minutes (enumerated value, defaulted to 1 minute).
•
Whether values for the resulting TimeStampedMetric should be visible to the controller's JMX
server (boolean, defaulted to false).
•
Whether values for the resulting TimeStampedMetric should be persisted (boolean, defaulted
to true).
The summary interval uses an enumerated data type to restrict the possible values to 1, 5, or 15
minutes. Also, note that while the value of most TimeStampedMetrics will likely be persisted over
time there may be cases, for example troubleshooting metrics, in which it is not desired to persist
the values as a time series but just to view them in real time via JMX.
The primary and secondary tags are provided as a means of grouping metrics for a specific
application. For example, consider an application that is to monitor router port statistics; it might
have collected a metric called TxFrames from every port of every router. The primary and
secondary tags would then be used to segment the occurrences of the TxFrames metric from each
router port. For some router A, port X, the four-tuple that identifies the specific instance of
TimeStampedMetric corresponding to that port might be as follows.
•
Application ID—com.acme.app
•
Primary tag—RouterA
•
Secondary tag—PortX
•
Metric name—TxFrames
There is a MetricDescriptor subclass that corresponds to each type of TimeStampedMetric. These
MetricDescriptor subtypes can only be created by using the corresponding MetricDescriptorBuilder
subclasses. The relationship between the desired TimeStampedMetric type, corresponding
MetricDescriptor subtype, and the MetricDescriptorBuilder subclasses to use to produce an
instance of the right MetricDescriptor subtype are summarized below.
Table 2 Metric Descriptor Subtype
TimeStampedMetric
Subtype
Corresponding
MetricDescriptor
Subtype
Required
MetricDescriptorBuilder
Subtype
TimeStampedCounter
CounterDescriptor
CounterDescriptorBuilder
TimeStampedGauge
GaugeDescriptor
GaugeDescriptorBuilder
TimeStampedHistogram
HistogramDescriptor
HistogramDescriptorBuilder
TimeStampedMeter
MeterDescriptor
MeterDescriptorBuilder
TimeStampedRatioGauge
RatioGaugeDescriptor
RatioGaugeDescriptorBuilder
49