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

[antonblr]

Thanos, Prometheus and Golang version used: v0.35.0

What happened:
Our setup: Grafana -> Query Frontend -> Query -> ...
Goal: 1 global data source to query all data/all tenants + multiple per-tenant datasources.

I was following https://thanos.io/tip/components/query.md/#tenancy in order to setup multi-tenancy on read path.
Enforcing tenancy is not an option, because we need a way to query across all tenants as well and this paragraph gives an impression that this is totally possible by passing tenant-id in the appropriate HTTP request header.

I've setup Grafana datasource to pass THANOS-TENANT: <tenant>, but Thanos returned metrics for all tenants. Once I added --query.enforce-tenancy flag to Thanos Query the aforementioned datasource start working as expected. But it broke global datasource, that allows to query across all the tenants (no metrics were returned).

What you expected to happen:

1. --query.enforce-tenancy is not set:

• return all metrics if THANOS-TENANT: <tenant> header is not provided (current behavior)
• return tenant-specific metrics if THANOS-TENANT: <tenant> header was provided (not working)

2. --query.enforce-tenancy is set:

• return nothing or default tenant metrics if THANOS-TENANT: <tenant> header is not provided (current behavior)
• return tenant-specific metrics if THANOS-TENANT: <tenant> header was provided (current behavior)

How to reproduce it (as minimally and precisely as possible):
Query Frontend flags related to tenant awareness functionality:

--query-frontend.forward-header=THANOS-TENANT
--query-frontend.tenant-header=THANOS-TENANT

Query flags:

--query.tenant-header=THANOS-TENANT

I've tested it through Grafana, but I guess the curl analog would be:

curl --header "THANOS-TENANT: <tenant>" "http://thanos-query-frontend.monitoring.svc.cluster.local:9090/api/v1/query?query=<some-metric>"

Full logs to relevant components:

Anything else we need to know:

[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.

[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.