Expensive metric validation in debug mode

[mxinden]

When run in debug mode, I think it is worth exploring running different validations on the registered metrics.

Examples:

• We could make sure a counter name does not end in _total as that is added automatically already.
• Registry::register could ensure that no duplicate metric names are being registered.
• Registry::register could ensure that the user did not provide an additional . in the HELP text. See Registry::register should not automatically append a period to the help text #56

I think a goal worth striving for is keeping the dependency tree small for the sake of compile times.

[AbhijithGanesh]

Heyy Max, I would like to work on this!

[mxinden]

Great. Let me know in case you need any help @AbhijithGanesh.

[AbhijithGanesh]

Definitely @mxinden

[AbhijithGanesh]

Can you explain about the expensive part of validating ? Does this mean this is taking more time/process ?

[mxinden]

Yes, correct, expensive in terms of hardware resources.

[AbhijithGanesh]

so here, I am trying to ensure the Registry::register doesn't allow duplication and optimize this for testing situations

[chylex]

I ran into an issue with a Family<String, Counter>. I thought this was valid since I only wanted one label, and that if this was not valid then the library would reject it at compile time or at least runtime, but encode ran without error and output something that was not valid openmetrics-text format:

# HELP apache_requests Number of received requests.
# TYPE apache_requests counter
apache_requests_total{first} 1
# EOF

This caused Prometheus to fail scraping with expected equal, got "BCLOSE". It would be nice if either the Family type definition, or at least the encode function could check that the labels are in a valid format.

[mxinden]

@chylex thanks for reporting here.

In general, yes I am in favor of checking proper formatting of labels in debug mode.

In your particular case, I am guessing that you provided an enum with Encode derived to the Family, correct? This is now impossible at compile time with #105. See latest alpha release. Would appreciate you testing this out.

[chylex]

@chylex thanks for reporting here.

In general, yes I am in favor of checking proper formatting of labels in debug mode.

In your particular case, I am guessing that you provided an enum with Encode derived to the Family, correct? This is now impossible at compile time with #105. See latest alpha release. Would appreciate you testing this out.

I provided what I considered to be the value of my label. I was missing the name of the label because I didn't learn how labels work properly, and thought that since I only had one "label", I should just pass its value.

The library didn't complain that Family<String, Counter> was a Family type that could never produce a valid encoding, and it proceeded to generate the invalid encoding which caused an error during scraping.

Once I found the issue, I corrected the Family type for my single-label metric to Family<(&'static str, String), Counter>.