Add a helper function to register all Collectors in a struct

[beorn7]

This is reflection based, but registration is not time-critical.

Example where this is would come in handy:
https://github.com/prometheus/prometheus/blob/92f31c3ec290fa744e167c0cb2daebfabae6c82b/tsdb/compact.go#L132-L140

Note that the fields in compactorMetrics needed to be exported (but
not compactorMetrics itself).

@bwplotka that's what I was referring to. Do you think this would work for you?

[bwplotka]

Thanks for this 👍 ❤️

Hm. I think it's definitely better than what we have now, it's harder to miss a metric registration. I think having those fields exported might be surprising and reviewer/author can forget about that... Why we cannot register unexported ones? Seems like we can read those fields: https://stackoverflow.com/questions/17981651/is-there-any-way-to-access-private-fields-of-a-struct-from-another-package.

But overall, this is, still, an extra step that someone has to make (MustRegisterFieldsWith). And especially with just exported fields, it's still easy to forget to make them uppercase.

As a result, I am not convinced if it's better than just promauto with each NewCounter(reg, opts...), NewXXX.. etc. 🤔

But thanks for this example! We will definitely consider this in Thanos - maybe even start with this.

[beorn7]

Thanks for the thoughtful feedback.

Why we cannot register unexported ones?

That seems to be a deliberate measure by the Go runtime. You cannot turn unexported fields into an interface (see CanInterface) in the code, and thus cannot treat them as Collectors.

I tried yet another idea today. I'll send you another WIP PR immediately.

[beorn7]

One way out here would be to panic if we encounter an unexported Collector. But at the moment, I think my other idea will work better. Just a minute…

[beorn7]

I'll close this as #713 seems more like the way to go.