Difference in parser behaviour compared to prometheus/common/expfmt

[zegelin]

The behaviour of the Python client's built-in text format parser differs to that of the parser found inside Prometheus itself.

Given the following (poorly formed, but apparently still valid) exposition output:

test_metric_a {hello="world"} 0 0
test_metric_b {hello="world"} 0 0
test_metric_a {hello="universe"} 0 0
test_metric_b {hello="universe"} 0 0

The Go expfmt TextParser.TextToMetricFamilies(...) function produces:

(map[string]*io_prometheus_client.MetricFamily) (len=2) {
 (string) (len=13) "test_metric_a": (*io_prometheus_client.MetricFamily)(0xc0000c4320)(name:"test_metric_a" type:UNTYPED metric:<label:<name:"hello" value:"world" > untyped:<value:0 > timestamp_ms:0 > metric:<label:<name:"hello" value:"universe" > untyped:<value:0 > timestamp_ms:0 > ),
 (string) (len=13) "test_metric_b": (*io_prometheus_client.MetricFamily)(0xc0000c4370)(name:"test_metric_b" type:UNTYPED metric:<label:<name:"hello" value:"world" > untyped:<value:0 > timestamp_ms:0 > metric:<label:<name:"hello" value:"universe" > untyped:<value:0 > timestamp_ms:0 > )
}

whereas the Python client's parser.text_fd_to_metric_families(...) function produces:

[
    Metric(test_metric_a, , unknown, , [Sample(name='test_metric_a', labels={'hello': 'world'}, value=0.0, timestamp=None, exemplar=None)]),
    Metric(test_metric_b, , unknown, , [Sample(name='test_metric_b', labels={'hello': 'world'}, value=0.0, timestamp=None, exemplar=None)]),
    Metric(test_metric_a, , unknown, , [Sample(name='test_metric_a', labels={'hello': 'universe'}, value=0.0, timestamp=None, exemplar=None)]),
    Metric(test_metric_b, , unknown, , [Sample(name='test_metric_b', labels={'hello': 'universe'}, value=0.0, timestamp=None, exemplar=None)])
]

As you can see the Go parser groups the samples into two untyped metric families with two samples each whereas the Python parser creates a new metric family for each sample.

[brian-brazil]

That's not the parser inside Prometheus itself. Is there a problem that this is causing you?

[asherf]

I am seeing a similar issue.
The parser in the python client doesn't process/parse timestamps.
Looking at the code/test, this seems to be intentional ?

I needed parsing for some work I am doing locally, so I have a fix for that here
I am happy to push this as a PR if there are no objections.
@brian-brazil

[brian-brazil]

Since openmetrics support was added, we should be parsing the timestamps.