Send to multiple exporters from tracer

[c24t]

This is an experimental branch to address #181. It changes Tracer such that it can use multiple exporters at once.

[zoidyzoidzoid]

If this is something we wanna support and not offload to opencensus-service, then the changes look good to me, other than the nitpicks.

[zoidyzoidzoid]

This should be type exporter and param exporter still, right? Judging from the contents.

[c24t]

It should! good catch.

[zoidyzoidzoid]

If someone tries to send something to multiple exporters, but one is incorrectly configured, we should try export to the others still, right, are we just gonna hope that each Exporter.emit swallows the exceptions and doesn't raise any?

[reyang]

I remember we had discussion about supporting multiple exporters and propagators, and people in that meeting generally agreed not to expose the interface for multiple exporters/propagators, but let people implement something like AggregatedExporter/Propagator. The idea is that you can implement a wrapper exporter that calls into multiple exporters, and you can decide what's the expected behavior - either abort the others if one failed, or continue.

Can we have a clarification here - do we want to have multiple exports/propagators interface for all languages? Or we want to stick with the aggregated approach?

[flands]

@reyang both Java and Go libraries support multiple destinations today. From a testing perspective or migration perspective this is a good feature to support. Of course, long term this could be handed off to the agent/collector, but requiring the agent/collector limits flexibility. I would propose supporting multiple destinations.

[reyang]

@flands thank you! What about multiple propagators?

[flands]

IMO this is less of a concern -- switching and testing is straightforward and migration path is cutover. Let me check OC service team and get back shortly.

[c24t]

@reyang I wasn't around for the discussion, can you link me? I don't think this is necessarily the best design, and I'm willing to believe we should add AggregatedExporter/Propagator classes instead.

@flands IMO if the API were closer to the java client's I think it would make sense to argue for a particular implementation, but as it is I think we have some flexibility here, and don't necessarily need to change the tracer.

[reyang]

@c24t I couldn't find the discussion, it was Jul. or Aug. this year.

I remember at that time we were talking about how flush API should be provided, whether the user would need to call flush for each individual exporter (if we support multi), or a top level flush at tracer level should be provided (and should we block the flush API until all exporters have finished flush, what do we do if one exporter failed).

[c24t]

Want to take the conversation around the design to #181?

[reyang]

Yep! #181 seems to be a good place for discussion.

[flands]

@c24t this appears to work, thanks! note, there are other parts of the library that also need to be updated. For example, opencensus/trace/ext/flask/flask_middleware.py

[ocervell]

@c24t looks cool. Does that mean we'll have one background thread / exporter here ?

[c24t]

Does that mean we'll have one background thread / exporter here ?

We will for each exporter that's using a background thread transporter, but we're blocking between calls to export. If we expect users to use many exporters with blocking transports at once we might want to make the calls from (e.g.) an async executor instead.