You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in #59, there is a question of how to report metrics that have been sampled. Although the metrics API currently does not specify a way to input sampled metrics, certain exporters may wish to perform sampling themselves. Here we propose a solution for representing sampled metrics in the protocol without touching on whether the API should support sampled inputs.
Each of the Int64Value, DoubleValue, SummaryValue, HistogramValue, and HistogramValue.Bucket types would support a new optional double value named weight, which, if omitted, has a default equal to 1.0, meaning that no sampling took place.
For Int64Value and DoubleValue types, there is an implicit count of 1 already, as these represent one measured value. The other types have explicit count fields. In each case, the value of weight is logically multiplied by the count, yielding an adjusted count due to sampling.
Consumers SHOULD use the value of count times weight as the total number of metric events being reported. Consumers MUST interpret count as the actual number of events collected, whereas weight MUST be considered a count multiplier due to sampling in the metrics export pipeline.
The text was updated successfully, but these errors were encountered:
As discussed in #59, there is a question of how to report metrics that have been sampled. Although the metrics API currently does not specify a way to input sampled metrics, certain exporters may wish to perform sampling themselves. Here we propose a solution for representing sampled metrics in the protocol without touching on whether the API should support sampled inputs.
Each of the Int64Value, DoubleValue, SummaryValue, HistogramValue, and HistogramValue.Bucket types would support a new optional
double
value namedweight
, which, if omitted, has a default equal to 1.0, meaning that no sampling took place.For Int64Value and DoubleValue types, there is an implicit count of 1 already, as these represent one measured value. The other types have explicit
count
fields. In each case, the value ofweight
is logically multiplied by the count, yielding an adjusted count due to sampling.Consumers SHOULD use the value of
count
timesweight
as the total number of metric events being reported. Consumers MUST interpretcount
as the actual number of events collected, whereasweight
MUST be considered a count multiplier due to sampling in the metrics export pipeline.The text was updated successfully, but these errors were encountered: