search

prometheus / common

Go libraries shared across Prometheus components and libraries.
Apache License 2.0
260 stars 320 forks source link

expfmt: Consider allowing empty MetricFamilies #50

Open beorn7 opened 8 years ago

beorn7 commented 8 years ago

Currently, a MetricFamily with no Metrics is invalid (i.e. it will never be created by encoders, and it will yield an error upon decoding).

As it turns out, client libraries that are ignorant of the protobuf exchange format are making use of empty metric families as represented in the text format, i.e.

# HELP blah some help
# TYPE blah gauge
# HELP blub another metric
# ...

This has never caused any trouble because the only entry point of the text format into the Prometheus universe is the text-format parser, which kicks out those metric families here.

@brian-brazil thinks empty metric families is something we should allow in general. That would require to change all code encoding and decoding protobuf, including the text-format parser. (Ideally, all that code is only in expfmt but there might be legacy.) Also, consumers of decoded protobuf have to be checked to deal gracefully with empty MetricFamilies, as they were so far guaranteed to not appear.

beorn7 commented 8 years ago

Alternative is to keep disallowing empty MetricFamilies. But we should clearly document that requirement. metrics.proto does not (and cannot) specify the requirement.

grobie commented 8 years ago

👍 for officially allowing empty MetricFamilies. I find it very useful to see defined but not observed metrics.

beorn7 commented 8 years ago

After ingestion, they will still not be visible (for as long as the Prometheus server doesn't handle meta data). But we can allow it in the exposition formats (and then, one day, the server might finally deal with meta data).

beorn7 commented 8 years ago

Filed https://github.com/prometheus/docs/issues/544 for the decision and documentation. Once that is settled, we change the implementation as required to resolve this issue.