Should the Metric structure adopt Prometheus metric best practices?

[ProbablePrime]

Firstly, thank you very much for making this exporter.

I love how easy it made dispelling some of the mystery of systems as complex as emails.

However, I'm also on my own metric journey for my own projects which lead me to read Prometheus' guidance on Metric naming. I based my custom metrics based on that document.

So then when it came time to create graphs for the postfix metrics I was confused and had to work a little harder to make progress. After awhile I realized that this was due to the metric structure of the postfix metrics.

For example: postfix_qmgr_messages_expired_total & postfix_qmgr_messages_removed_total

Seem to not follow the best practices on labelling.

Some of the above guidance reads:

Use labels to differentiate the characteristics of the thing that is being measured

And provides an example:

api_request_duration_seconds - differentiate request stages: stage="extract|transform|load"

Based on this what I expected was:

postfix_qmgr_messages_total{state=expired} XX
postfix_qmgr_messages_total{state=removed} XX

This makes some queries, visualization and calculations very easy to do and also provides a great deal of "self-documentation" to the metrics. It's easy to see the possible values and get the flow through the queue into a visualization. In some cases it can also reduce load as queries can be optimized based on the labels and state.

There are other totals that could also do with this treatment. We could even explore exporting an overall "totals" metric that reports the stages and outcomes of each part of postfix.

Would there be any interest in adding metrics in that structure to this exporter somehow?

We'd probably have to preserve the existing metric structure, but adding additional metrics with the same values as already instrumented data should be doable.