Generally, this is solved with a metrics exporter, not by making the instrumentation code itself dynamic/pluggable.

Personally, I'm not super enamored with opencensus, but as its successor (opentelemetry) still has not stabilized their metrics APIs it wasn't a viable alternative. Primarily the reason we're using opencensus is precedent with related services; it's how libraries like pubsub are instrumented as well.

I see. In that case I guess we're fine, as long as people can plugin their own system by registering the desired exporter, be it an existing one or a custom one, it should be fine I guess. Thank you for that info :) every day is a school day

Shall I close this issue by the way, as for me this is sufficient of an answer. The only thing that I would suggest is to add this information to the documentation, as it might be obvious if you're familiar with the ecosystem, but to me that answer didn't occur to me at all. Either way, thanks for the help :) Definitely helped me out.

I'll go ahead and close this. I've already got a task to show this more clearly through some samples.

However, if others come across this report, here's a snippet from a benchmarking server that sets up metrics exporting into cloud monitoring via contrib.go.opencensus.io/exporter/stackdriver (cloud monitoring was formerly branded as stackdriver, hence the package name):

func (s *Server) startExporter() error {
	exporter, err := stackdriver.NewExporter(stackdriver.Options{
		ProjectID: s.projectID,
	})
	if err != nil {
		return err
	}

	if err := view.Register(managedwriter.DefaultOpenCensusViews...); err != nil {
		return err
	}

	if err := exporter.StartMetricsExporter(); err != nil {
		return err
	}

	// Add flush and stop to shutdown tasks.
	s.shutdownFuncs = append(s.shutdownFuncs, func() {
		exporter.Flush()
		exporter.StopMetricsExporter()
	})
	return nil
}