search

census-instrumentation / opencensus-specs

Apache License 2.0
188 stars 50 forks source link

Decouple producers and consumers #72

Open DazWilkin opened 6 years ago

DazWilkin commented 6 years ago

Apologies if filed in the wrong repo; not clear where cross-cutting concerns should be represented.

I believe an implicit commitment from OpenCensus ought to be that OpenCensus-annotated code should be loosely-bound to consuming services (Prometheus, Stackdriver). Rather, once code is annotated with OpenCensus libraries, users of such code should be permitted to arbitrarily choose these Services at runtime (through config).

This commitment appears to not be inherent|true today.

In my limited experience using OpenCensus (Golang, Java), code is required to explicitly reference the intended|desired consuming service:

exporter, err := stackdriver.NewExporter(stackdriver.Options{})

or:

StackdriverTraceExporter.createAndRegister(StackdriverTraceConfiguration.builder()

along with associated imports.

I anticipate OpenCensus users will be willing to revise code to annotate it to reference OpenCensus but that they may balk at the prospect of then also specifying the consuming service.

I'd expect|prefer:

exporter, err := opencensus.NewExporter()

and then runtime config specifying a specific implementation of an OpenCensus Exporter with relevant configuration.

/cc: @mtwo @shahprit

rakyll commented 6 years ago

Related to https://github.com/census-instrumentation/opencensus-specs/issues/34.

IMHO, we should can also implement a defacto discoverable out-of-the-process exporter. Then, if the user is having a problem and hadn't linked an exporter in their service, they can deploy the exporter process and upload the data to whatever backend they choose.

savaki commented 6 years ago

I think this may make sense as a contrib package, but I strongly disagree with this being included in the standard package. I can't speak for other languages, but for Go, I believe the opencensus-go package already has too large a footprint and should just contain the core implementation without exporters unless the exporters can be written without an external dependencies. Otherwise, it forces the users of opencensus to include far more packages than they would otherwise require.

bogdandrutu commented 6 years ago

@savaki we are working actively to remove all the exporters for go because of how "go get" works. In other languages like java the problem is not visible because we export individual artifacts for each exporters.