Open
Description
When implementing Created Timestamp support in Prometheus OM's parser, we've faced many challenges with the current format:
- If the parser was not ready to parse created timestamps, how they are exposed looks precisely the same as how a usual metric looks. CT would be ingested as a metric and could lead to a 50% increase in metric ingestion if the target exposes mainly counters.
- Since they look like metrics, parsers need extra logic to differentiate actual metrics that end with the
_created
suffix. - No strict ordering requires state handling for complex metric types like histograms and summaries.
We'd love to address all these problems with OpenMetrics 2.0. In the last Prometheus CT WG call, we discussed OM for a bit and came up with the following ideas:
- Expose CT similarly to the way we expose metadata (with a comment):
# TYPE example_metric counter
# HELP example_metric An example counter with a created timestamp
# CT example_metric 1234
example_metric 1
# CT example_metric{foo="bar"} 4312
example_metric{foo="bar"} 2
- Expose CT inline with the metric
# TYPE example_metric counter
# HELP example_metric An example counter with a created timestamp
example_metric 1 ct1234
example_metric{foo="bar"} 2 ct4312
We're opening this issue to discuss both ideas or new ones if anyone is thinking of another approach.
Metadata
Metadata
Assignees
Type
Projects
Status
Todo