query: Passing `THANOS-TENANT: <tenant>` header has no effect unless `--query.enforce-tenancy` is set about thanos

[jacobbaungard]

There is probably some room for improvement on the wording there, happy to take suggestions/PRs on how to word this more clearly.

The "Tenant Metrics" section is about annotating Thanos' "self-monitoring metrics" with tenant information - i.e this is about metrics Thanos exports about Thanos itself. For example the Thanos Query component exports metrics such as http_requests_total or thanos_store_api_query_duration_seconds_bucket (exposed by querier even though it's prefixed thanos_store...). To these metrics a tenant label matching the tenant of the incoming requests is added, which allows one to do some kind of reasoning of various things on the query path on a per tenant-level. A basic question this allow us to answer could be "which tenant made the most queries". This can be useful even without any enforcement enabled.

[jacobbaungard]

This was not a scenario we considered when designing the tenant feature, so yes this won't work at the moment at least. As it is now you can either have enforcement fully enabled on all queries, or not at all. When no tenant header is sent along with the request to the querier, it will use the default tenant for enforcement which can be configured using query.default-tenant-id.

For now you'd need to setup two different query paths, one for global view where the tenant enforcement is disabled in the querier, and another where enforcement is enabled.

The reason for having tenant information at all when enforcement is disabled, is in order to get self-monitoring metrics for each tenant (for example to determine the query load on a per-tenant basis).

[antonblr]

Thanks @jacobbaungard for the input.

Not sure if it just me or documentation could be more clear on that - I read the "Tenant Metrics" paragraph and I was under the impression that all I need to do is pass the tenant id along with the header to get the tenant specific metrics.

Then the next paragraph "Tenant Enforcement" tells how you can actually enforce this behavior, if you want. But from your explanation they should be combined into one (e.g. there is no tenant-specific metrics without enforcement and vice versa).

Tenant Metrics
Tenant information is captured in relevant Thanos exported metrics in the Querier, Query Frontend and Store. In order make use of this functionality requests to the Query/Query Frontend component should include the tenant-id in the appropriate HTTP request header as configured with --query.tenant-header. The tenant information is passed through components (including Query Frontend), down to the Thanos Store, enabling per-tenant metrics in these components also. If no tenant header is set to requests to the query component, the default tenant as defined by --query.tenant-default-id will be used.

Tenant Enforcement
Enforcement of tenancy can be enabled using --query.enforce-tenancy. If enabled, queries will only fetch series containing a specific matcher, while evaluating PromQL expressions. The matcher label name is --query.tenant-label-name and the matcher value matches the tenant, as sent to the querier in the HTTP header configured with --query-tenant-header. This functionality requires that metrics are injected with a tenant label when ingested into Thanos. This can be done for example by enabling tenancy in the Thanos Receive component.