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
@@ -627,32 +647,10 @@ Integer numbers MUST NOT have a decimal point. Examples are `23`, `0042`, and `1
627
647
628
648
Floating point numbers MUST be represented either with a decimal point or using scientific notation. Examples are `8903.123421` and `1.89e-7`. Floating point numbers MUST fit within the range of a 64-bit floating point value as defined by IEEE 754, but MAY require so many bits in the mantissa that results in lost precision. This MAY be used to encode nanosecond resolution timestamps.
629
649
630
-
Arbitrary integer and floating point rendering of numbers MUST NOT be used for "quantile" and "le" label values as in section "Canonical Numbers". They MAY be used anywhere else numbers are used.
631
-
632
650
###### ComplexValues
633
651
634
652
ComplexValue is represented as structured data with fields. There MUST NOT be any whitespace around fields. See the ABNF for exact details about the format and possible values.
635
653
636
-
###### Considerations: Canonical Numbers
637
-
638
-
Numbers in the "le" label values of histograms and "quantile" label values of summary metrics are special in that they're label values, and label values are intended to be opaque. As end users will likely directly interact with these string values, and as many monitoring systems lack the ability to deal with them as first-class numbers, it would be beneficial if a given number had the exact same text representation.
639
-
640
-
Consistency is highly desirable, but real world implementations of languages and their runtimes make mandating this impractical. The most important common quantiles are 0.5, 0.95, 0.9, 0.99, 0.999 and bucket values representing values from a millisecond up to 10.0 seconds, because those cover cases like latency SLAs and Apdex for typical web services. Powers of ten are covered to try to ensure that the switch between fixed point and exponential rendering is consistent as this varies across runtimes. The target rendering is equivalent to the default Go rendering of float64 values (i.e. %g), with a .0 appended in case there is no decimal point or exponent to make clear that they are floats.
641
-
642
-
Exposers MUST produce output for positive infinity as +Inf.
643
-
644
-
Exposers SHOULD produce output for the values 0.0 up to 10.0 in 0.001 increments in line with the following examples:
Parsers MUST NOT reject inputs which are outside of the canonical values merely because they are not consistent with the canonical values. For example 1.1e-4 must not be rejected, even though it is not the consistent rendering of 0.00011.
651
-
652
-
Exposers SHOULD follow these patterns for non-canonical numbers, and the intention is by adjusting the rendering algorithm to be consistent for these values that the vast majority of other values will also have consistent rendering. Exposers using only a few particular le/quantile values could also hardcode. In languages such as C where a minimal floating point rendering algorithm such as Grisu3 is not readily available, exposers MAY use a different rendering.
653
-
654
-
A warning to implementers in C and other languages that share its printf implementation: The standard precision of %f, %e and %g is only six significant digits. 17 significant digits are required for full precision, e.g. `printf("%.17g", d)`.
655
-
656
654
##### Timestamps
657
655
658
656
Timestamps SHOULD NOT use exponential float rendering for timestamps if nanosecond precision is needed as rendering of a float64 does not have sufficient precision, e.g. `1604676851.123456789`.
@@ -754,38 +752,42 @@ MetricPoints MUST NOT be interleaved.
754
752
A correct example where there were multiple MetricPoints and Samples within a MetricFamily would be:
755
753
756
754
```openmetrics-add-eof
757
-
# TYPE foo_seconds summary
758
-
# UNIT foo_seconds seconds
759
-
foo_seconds_count{a="bb"} 0 123
760
-
foo_seconds_sum{a="bb"} 0 123
761
-
foo_seconds_count{a="bb"} 0 456
762
-
foo_seconds_sum{a="bb"} 0 456
763
-
foo_seconds_count{a="ccc"} 0 123
764
-
foo_seconds_sum{a="ccc"} 0 123
765
-
foo_seconds_count{a="ccc"} 0 456
766
-
foo_seconds_sum{a="ccc"} 0 456
755
+
# TYPE foo stateset
756
+
foo{entity="controller",foo="a"} 1.0
757
+
foo{entity="controller",foo="bb"} 0.0
758
+
foo{entity="controller",foo="ccc"} 0.0
759
+
foo{entity="replica",foo="a"} 1.0
760
+
foo{entity="replica",foo="bb"} 0.0
761
+
foo{entity="replica",foo="ccc"} 1.0
767
762
```
768
763
769
764
An incorrect example where Metrics are interleaved:
770
765
771
-
```
772
-
# TYPE foo_seconds summary
773
-
# UNIT foo_seconds seconds
774
-
foo_seconds_count{a="bb"} 0 123
775
-
foo_seconds_count{a="ccc"} 0 123
776
-
foo_seconds_count{a="bb"} 0 456
777
-
foo_seconds_count{a="ccc"} 0 456
766
+
```openmetrics-add-eof
767
+
# TYPE foo stateset
768
+
foo{entity="controller",foo="a"} 1.0
769
+
foo{entity="controller",foo="bb"} 0.0
770
+
foo{entity="controller",foo="ccc"} 0.0
771
+
foo{entity="replica",foo="a"} 1.0
772
+
foo{entity="replica",foo="bb"} 0.0
773
+
foo{entity="replica",foo="ccc"} 1.0
774
+
foo{entity="controller",foo="a"} 1.0
775
+
foo{entity="controller",foo="bb"} 0.0
776
+
foo{entity="controller",foo="ccc"} 0.0
778
777
```
779
778
780
779
An incorrect example where MetricPoints are interleaved:
781
780
782
-
```
781
+
```openmetrics-add-eof
783
782
# TYPE foo_seconds summary
784
783
# UNIT foo_seconds seconds
785
-
foo_seconds_count{a="bb"} 0 123
786
-
foo_seconds_count{a="bb"} 0 456
787
-
foo_seconds_sum{a="bb"} 0 123
788
-
foo_seconds_sum{a="bb"} 0 456
784
+
# TYPE foo stateset
785
+
foo{entity="controller",foo="a"} 1.0
786
+
foo{entity="controller",foo="bb"} 0.0
787
+
foo{entity="replica",foo="a"} 1.0
788
+
foo{entity="controller",foo="ccc"} 0.0
789
+
foo{entity="replica",foo="bb"} 0.0
790
+
foo{entity="replica",foo="ccc"} 1.0
789
791
```
790
792
791
793
#### Metric types
@@ -945,47 +947,35 @@ An example of a Metric with no labels and a MetricPoint with Sum, Count and Star
The MetricPoint's Sum Value Sample MetricName MUST have the suffix `_sum`. The MetricPoint's Count Value Sample MetricName MUST have the suffix `_count`. The MetricPoint's Classic Bucket values Sample MetricNames MUST have the suffix `_bucket`.
964
+
The MetricPoint's value MUST be a ComplexValue.
965
+
966
+
The ComplexValue MUST include the Count, Sum and Classic Bucket values as the fields `count`, `sum`, `bucket`, in this order.
965
967
966
968
If present the MetricPoint's Start Timestamp MUST be inlined with the Metric point with a `st@` prefix. If the value's timestamp is present, the Start Timestamp MUST be added right after it. If exemplar is present, the Start Timestamp MUST be added before it. Start Timestamp MUST be appended to all Classic Bucket values, to the MetricPoint's Sum and MetricPoint's Count.
967
969
968
-
Classic Buckets MUST be sorted in number increasing order of "le", and the value of the "le" label MUST follow the rules for Canonical Numbers.
970
+
Classic Buckets MUST be sorted in number increasing order of their threshold.
969
971
970
972
All Classic Buckets MUST be present, even ones with the value 0.
971
973
972
-
An example of a Metric with no labels and a MetricPoint with Sum, Count, and Start Timestamp values, and with 12 Classic Buckets. A wide and atypical but valid variety of “le” values is shown on purpose:
974
+
An example of a Metric with no labels and a MetricPoint with Sum, Count, and Start Timestamp values, and with 12 Classic Buckets. A wide and atypical but valid variety of bucket threshold values is shown on purpose:
The MetricPoint's Sum Value Sample MetricName MUST have the suffix `_gsum`. The MetricPoint's Count Value Sample MetricName MUST have the suffix `_gcount`. The MetricPoint's Classic Bucket values Sample MetricNames MUST have the suffix `_bucket`.
1049
+
The MetricPoint's value MUST be a ComplexValue.
1050
+
1051
+
The ComplexValue MUST include the Gcount, Gsum and Classic Bucket values as the fields `count`, `sum`, `bucket`, in this order.
1070
1052
1071
-
Classic Buckets MUST be sorted in number increasing order of "le", and the value of the "le" label MUST follow the rules for Canonical Numbers.
1053
+
Classic Buckets MUST be sorted in number increasing order of their threshold.
1072
1054
1073
1055
An example of a Metric with no labels, and one MetricPoint value with no Exemplar with no Exemplars in the buckets:
0 commit comments