Foglight for Virtualization Enterprise Edition 8.9.3 - Web Component Guide

Time Range Related to Observations

A TimeRange for a Metric Observation can be specified in various ways, but it is always ultimately composed of a range of date-time objects, and a granularity. The granularity can be RAW, which means that data observations should be shown in the metric history with the smallest available granularity, or a number of milliseconds, for example, 300,000 for 5 minutes. It can also be AUTO, for example, a numeric value of ‑2, meaning the code will pick the best granularity based on the time range.

The list of history Metric Values must be in ascending order of date-time.

When the granularity is RAW, indicated by the numeric value ‑1, history observations will be added with the smallest available granularity. Different observations within the history may cover differently-sized time intervals, and different metrics in the same time range using RAW granularity may have different numbers of history observations in the case of unrelated time intervals.

When the granularity is a number of milliseconds, in each history metric value, the difference between the end time and the start time (in milliseconds) must equal the granularity. Each successive history object’s start time should be the previous history object’s end time. That is, each history object must cover exactly one granularity interval.

Exactly how the start times and end times of the history objects are related to the start time and end time of the entire non-RAW time range is not specified as a Web Component Framework requirement. For one thing, the length of the entire time range may not be an even multiple of the granularity. Reasonable options include starting the first history object’s start time at the exact start time of the time range, or starting it at the start time of the time range less half the granularity. However, the start time of the first history object should be no greater than the start time of the time range, and the end time of the last history object should be no less than the end time of the time range.

When there are multiple metrics calculated for the same non-RAW time range (whether they are different metrics on the same object, or the same metric on different objects), they must have exactly the same number of history objects as each other, and the start times and end times of the history objects at the same indices in their lists must be identical.

If there are no agent observations that correspond to a history object within a certain granularity interval in a non-RAW time range, a history object is still created, with the appropriate start time and end time, but none of the value properties are filled in.

Metric Observations

An observation of a numerical value is called a metric.

Data collected by Foglight® agents is generally expected to be packaged into a Metric data object. Certain components, such as the chart components, must be bound to Metric objects to function.

Metric definitions must specify the unit property in the Metric’s containing Property class. The unit is used to display numeric data. In particular, the unit’s precision property is used by some components (such as charts) and renderers to ensure the correct number of decimal places are used when rendering data. If the Metric’s precision is desired to be different than its unit’s precision, you can set the precision directly on the Metric’s containing Property class using the precision property.

Metrics must conform to the following schema:

Enum Observations

Data collected by agents is sometimes collected into an EnumObservation data object. Certain components must be bound to EnumObservation objects to function. EnumObservations must conform to the following schema:

Context

Context is the collection of data that defines the essential dynamic information that the view requires. If a view is supposed to display information about one application server, then the context specifies which application server.

If the context of a view has been set, then the view can use that value by specifying the named value of the context via a key. Similarly, if a view has a given named value in its context, and a link takes it to another view, then that new view can get access to that value by specifying its name as a context input.

For more information, see Context Tab.