prometheus
expfmt: Consider allowing empty MetricFamilies
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.
Alternative is to keep disallowing empty MetricFamilies. But we should clearly document that requirement. metrics.proto does not (and cannot) specify the requirement.
👍 for officially allowing empty MetricFamilies. I find it very useful to see defined but not observed metrics.
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).
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.