Add ability to distinguish traces from different services located in the same JVM

[Jokser]

The issue is coming from a discussion census-instrumentation/opencensus-java#1952

There is a problem about how to distinguish traces from different services located in the same JVM. I mean service in terms of Zipkin exporter configuration. As I see the exporter has "service" field which represents a logical separation between some business and internal processes.
Let's suppose the situation if you have some web-service that does some business logic and embedded database for storing/querying a data to it. Physically they share the same JVM but logically it's two different service - business and db.
At the moment we can use tags to separate spans come from business service and db but both of them will relate to the same service.
This problem can be resolved by using separated tracing components stacks in the same JVM but the ability to create several tracing components is a difficult task at the moment because of the singleton nature of some internals.
Another approach is that we can use different span exporters with different "service" parameters. At the moment all spans in JVM go through all registered exporters. We can add span filtering for exporters that some spans go to one exporter while some to another using "resource" field in Span.
WDYT?

[codefromthecrypt]

if you go with exporter dispatch approach, you should probably implement localRoot so that the service label can be applied consistently through the subtree. that's what it was made for (in brave)

…

On Fri, Jul 26, 2019 at 12:13 AM Pavel Kovalenko ***@***.***> wrote: The issue is coming from a discussion census-instrumentation/opencensus-java#1952 <census-instrumentation/opencensus-java#1952> There is a problem about how to distinguish traces from different services located in the same JVM. I mean service in terms of Zipkin exporter configuration. As I see the exporter has "service" field which represents a logical separation between some business and internal processes. Let's suppose the situation if you have some web-service that does some business logic and embedded database for storing/querying a data to it. Physically they share the same JVM but logically it's two different service - business and db. At the moment we can use tags to separate spans come from business service and db but both of them will relate to the same service. This problem can be resolved by using separated tracing components stacks in the same JVM but the ability to create several tracing components is a difficult task at the moment because of the singleton nature of some internals. Another approach is that we can use different span exporters with different "service" parameters. At the moment all spans in JVM go through all registered exporters. We can add span filtering for exporters that some spans go to one exporter while some to another using "resource" field in Span. WDYT? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#472?email_source=notifications&email_token=AAAPVV63JGFVTANULP4CTSLQBHGKZA5CNFSM4IG4IETKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HBQWNYA>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAPVVYALFNQAJNPFWYXXWLQBHGKZANCNFSM4IG4IETA> .

[pavolloffay]

hi @Jokser, It seems what you are describing is related to #308 and PR #350.

The PR #350 adds the ability to have multiple tracers.

[Jokser]

@pavolloffay @adriancole Thank you for the responses. Does it mean that the approach described in the issue you mentioned will only way to resolve the problem described here?
If you have the ability to create multiple tracers do we really need the ability to filter spans in exporters? Or it may be a useful feature anyway?

[codefromthecrypt]

multiple tracers will work if similarly scoped down the tree of requests and don't make local calls to things handled by other tracers. if all tracers share the same exporter, you can increase the effectiveness of the batching handled there. If they share the same sampling impl, this can help avoid overrunning the policy you want because otherwise a rate is increased by tracer count (unless the sampler itself has some global coordination)

[jkwatson]

Now that the exporters all use the Resource service.name attribute, and we can very easily have multiple instances of the SDK, I think we can close this issue.