Chat now with support
Chat mit Support

Foglight 7.1.0 - Web Component Guide

Introducing the Web Component Framework The Web Component Framework Configuring Views and Context Queries Functions Bindings Additional Components

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.

1
From the navigation panel, under Dashboards, click Configuration > Data.

Metrics must conform to the following schema:

String

Unique ID.

String

Name of the metric, localizable.

MetricValue

Value for entire time range.

MetricValue

Value of the last recorded sample.

MetricValue

Value for last interval in time range.

MetricValue; is-many = true

List of values for each interval in the time range.

String

Unique ID.

Date

Start time of the interval, exclusive.

Date

End time of the interval, inclusive.

Long

Period covered by this interval in milliseconds.

(This value may be lower than the difference between endTime and startTime, if the agent does not collect data during the entire interval.)

Long

Number of agent samples in this interval.

Number

Minimum value of all agent samples in this interval.

Number

Maximum value of all agent samples in this interval.

Number

Average value of all agent samples in this interval.

Number

Sum of all agent samples in this interval.

Number

Sum of the squares of all agent samples in this interval.

Number

Standard deviation of all agent samples in this interval.

Number

Baseline minimum value of all agent samples in this interval.

Number

Baseline maximum value of all agent samples in this interval.

ThresholdValue is-many = true

List of thresholds for this interval.

String

Unique ID

Bound

Upper bound of threshold range

Bound

Lower bound of threshold range

Enum

State associated with this threshold range

String

Unique name.

Number

Value of bound. If set to Double.POSITIVE_INFINITY, the threshold is assumed to stretch to infinity.

Boolean

False if the bound includes value, True if it does not.

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:

String

Unique name

String

Name of metric, localizable

EnumObservationValue

Value for entire time range

EnumObservationValue

Value for last interval in time range

EnumObservationValue; is-many = true

List of values for each interval in time range

String

Unique name

Date

Start time of interval, exclusive

Date

End time of interval, inclusive

Number

Index of this observation

Number

Enum value of this observation

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.

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen