From 4eb62551b87d08638e6436f8d7589231a5ac1649 Mon Sep 17 00:00:00 2001 From: David Greaves Date: Mon, 20 Nov 2023 12:18:28 +0000 Subject: [PATCH] Fix Heading formatting Metric and Label Name Characters was not properly marked up. --- specification/OpenMetrics.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/specification/OpenMetrics.md b/specification/OpenMetrics.md index 7f3e938..2347272 100644 --- a/specification/OpenMetrics.md +++ b/specification/OpenMetrics.md @@ -1205,7 +1205,8 @@ Labels of a Metric should be to the minimum needed to ensure uniqueness as every Experience has shown that downstream ingestors find it easier to work with separate total and failure MetricFamiles rather than using {result="success"} and {result="failure"} Labels within one MetricFamily. Also it is usually better to expose separate read & write and send & receive MetricFamiles as full duplex systems are common and downstream ingestors are more likely to care about those values separately than in aggregate. All of this is not as easy as it may sound. It's an area where experience and engineering trade-offs by domain-specific experts in both exposition and the exposed system are required to find a good balance. -Metric and Label Name Characters + +## Metric and Label Name Characters OpenMetrics builds on the existing widely adopted Prometheus text exposition format and the ecosystem which formed around it. Backwards compatibility is a core design goal. Expanding or contracting the set of characters that are supported by the Prometheus text format would work against that goal. Breaking backwards compatibility would have wider implications than just the wire format. In particular, the query languages created or adopted to work with data transmitted within the Prometheus ecosystem rely on these precise character sets. Label values support full UTF-8, so the format can represent multi-lingual metrics.