Optionally supply tenancy when reporting spans #3742
Conversation
Signed-off-by: Ed Snible <snible@us.ibm.com>
Signed-off-by: Ed Snible <snible@us.ibm.com>
Codecov Report
@@ Coverage Diff @@
## main #3742 +/- ##
==========================================
- Coverage 97.49% 97.48% -0.02%
==========================================
Files 271 271
Lines 16004 16017 +13
==========================================
+ Hits 15603 15614 +11
- Misses 317 319 +2
Partials 84 84
Continue to review full report at Codecov.
|
| return grpc.NewCollectorProxy(builder, opts.AgentTags, opts.Metrics, opts.Logger) | ||
| md := metadata.New(map[string]string{}) | ||
| if builder.CollectorTenancyHeader != "" { | ||
| md = metadata.New(map[string]string{builder.CollectorTenancyHeader: builder.CollectorTenant}) |
There was a problem hiding this comment.
With this change every span received by the Agent will be tagged with a single tenant when forwarded to Collector. While this is a viable deployment model in some situations, I don't think it's ultimately the right one, especially when the Agent runs as a host agent receiving data from potentially multiple co-located applications (which could be different tenants).
For example, this makes it impossible to test multi-tenancy with all-in-one if the other tenants are also going through the agent.
My preference would be for the agent to extract the tenant directly from the spans it receives, and the current solution could be an opt-in extension to either override the tenant or inject it when empty (for cases when agent is used as a sidecar).
|
Closing in favor of #3750 |
Signed-off-by: Ed Snible snible@us.ibm.com
With #3688 we introduced
--multi_tenancy.enabled=truewhich enables the collector to reject spans with missing or invalid tenant header.This PR restores correct span reporting when tenancy is enabled. Without this change, when a multi-tenant Jaeger gets a (currently untenanted) query, it reports spans related to handling the query without a tenant. Those (usually) self spans are rejected.
Some of the work in this PR was previously done in the draft PR for query tenancy, #3735 . That PR was getting big so the reporting stuff will be removed and handled in this PR.