Do not prefix Thanos objstore client metrics and fix instrumentation in querier

[pracucci]

What this PR does:
Currently Thanos objstore metrics are prefixed by cortex_<service>_. This leads to two issues:

1. There's no future-proof way to build dashboards including objstore metrics across all Cortex services (because we may change prefixes, add new services, etc). May look a remote possibility, but to give a concrete example @jtlisi is working to use it in the ruler (Transition ruler to use Thanos bucket clients #2543).
2. It's against how Prometheus was designed (see whole discussion here)

In this PR I propose to:

1. Remove the metrics prefixing
2. Adding a {component="name"} label
3. Instrument the bucket directly in the factory so that we don't forget about it (I forgot in pkg/querier/blocks_store_queryable.go - the bug fix is not mentioned in the CHANGELOG because the whole store-gateway work doesn't appear in the CHANGELOG yet)

Which issue(s) this PR fixes:
N/A

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[pstibrany]

I would prefer to add instrumentation in tsdb.NewBucketClient instead of individual object-store specific factories. That way it's in the single place, and we always create our bucket clients through that function anyway. WDYT?

[pracucci]

I would prefer to add instrumentation in tsdb.NewBucketClient instead of individual object-store specific factories. That way it's in the single place, and we always create our bucket clients through that function anyway. WDYT?

I'm OK with it. The reason why I did it for every single backend storage is because the NewBucketClient for a specific backend (ie. s3.NewBucketClient) are exposed and wrapping the instrumentation there would make sure that none forgets about instrumentation either when we use the factory or the single backend. WDYT?

[pstibrany]

I'm OK with it. The reason why I did it for every single backend storage is because the NewBucketClient for a specific backend (ie. s3.NewBucketClient) are exposed and wrapping the instrumentation there would make sure that none forgets about instrumentation either when we use the factory or the single backend. WDYT?

I see your point, but one can also use factory methods from Thanos and then get unwrapped bucket clients. I think we should be consistent. Furthermore our own code inside Cortex doesn't do that (apart from tests). But this isn't a big deal.

Thanks for fixing this, it will make working with these metrics easier.

[pracucci]

I'm OK with it. The reason why I did it for every single backend storage is because the NewBucketClient for a specific backend (ie. s3.NewBucketClient) are exposed and wrapping the instrumentation there would make sure that none forgets about instrumentation either when we use the factory or the single backend. WDYT?

I see your point, but one can also use factory methods from Thanos and then get unwrapped bucket clients. I think we should be consistent. Furthermore our own code inside Cortex doesn't do that (apart from tests). But this isn't a big deal.

Thanks for fixing this, it will make working with these metrics easier.

I've applied your suggestion. Thanks for the review!