Prometheus protobuf message question (issue# 547)

[devtk...@gmail.com]

Prometheus data model docs talk only about Metric name and labels. The protobuf message has the concept of metric family. How are these related ? Since there is only 1 name in the protobuf MetricFamily struct , I'm assuming that MetricFamily is metric name and Metrics are the different samples with labelPairs. Is that correct ?

In my understanding, as per text exposition format, only 1 HELP and optionally 1 TYPE message should be generated per metric family

running the following text through TextToMetricFamilies API returns error

text format parsing error in line 4: second HELP line for metric name "seastar_reactor"

# HELP seastar_reactor Scylla server statistics
# TYPE seastar_reactor counter
seastar_reactor{shard="0",type="derive",metric="aio-read-bytes",instance="mw104"} 8.21323776e+09
# HELP seastar_reactor Scylla server statistics
# TYPE seastar_reactor counter
seastar_reactor{shard="0",type="derive",metric="aio-write-bytes",instance="mw104"} 1.81659648e+09
# HELP seastar_reactor Scylla server statistics
# TYPE seastar_reactor gauge
seastar_reactor{shard="0",type="gauge",metric="load",instance="mw104.sjc.aristanetworks.com"} 0
# HELP seastar_reactor Scylla server statistics
# TYPE seastar_reactor gauge
seastar_reactor{shard="0",type="gauge",metric="queued-io-requests",instance="mw104"} 0

I have a service which returns metrics in protobuf format only. Decoding the HTTP response into protobuf works without errors and gives me 1 metric family for each line above. I'm confused by that. Shouldn't there be 1 metricfamily for all of the lines above ?

Then I converted each MetricFamily to text using expfmt.MetricFamilyToText
So the HELP and TEXT lines could be because of this API and so the real issue is that the protobuf message has different MetricFamilies instead of one.

I also saw the following open issue which confirms that protobuf accepts repeated MetricFamilies but text doesnt. The service I'm interacting with supports protobuf only so the native prometheus clients work fine but some other client breaks.

https://github.com/prometheus/docs/issues/547

For this given piece of data, how should it be represented in protobuf ?

Thanks
-krishna

[Björn Rabenstein]

On 10 February 2017 at 16:15, <devtk...@gmail.com> wrote:

Prometheus data model docs talk only about Metric name and labels. The protobuf message has the concept of metric family. How are these related ? Since there is only 1 name in the protobuf MetricFamily struct , I'm assuming that MetricFamily is metric name and Metrics are the different samples with labelPairs. Is that correct ?

The definitions are, unfortunately, not always used consistently. The data model is the following:

- A Metric is a unique combination of label pairs, including the name as a "special label pair".

- A Sample is a sample value in combination with a Metric.

- A MetricFamily are all Metrics of the same name.

In my understanding, as per text exposition format, only 1 HELP and optionally 1 TYPE message should be generated per metric family

Yes.

 

I have a service which returns metrics in protobuf format only. Decoding the HTTP response into protobuf works without errors and gives me 1 metric family for each line above. I'm confused by that. Shouldn't there be 1 metricfamily for all of the lines above ?

Yes. As explained in [the issue you linked below](https://github.com/prometheus/docs/issues/547), the server currently tolerates duplicate MetricFamilies, although the spec doesn't allow it. The tolerance doesn't intend to change the spec, it's merely following the [robustness principle](https://en.wikipedia.org/wiki/Robustness_principle).

 

For this given piece of data, how should it be represented in protobuf ?

You should not have duplicate MetricFamily names in a single exposition. Otherwise, your exposition may be legitimately rejected by any standard compliant scraper. Prometheus client libraries will (or should) make sure of that.

--

Björn Rabenstein, Engineer
http://soundcloud.com/brabenstein

SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany
Managing Director: Alexander Ljung | Incorporated in England & Wales with Company No. 6343600 | Local Branch Office | AG Charlottenburg  | HRB 110657B

[kthom...@arista.com]

Thanks for confirmation.
The team who developed the service I was using is fixing the protobuf exposition.