Skip to content
This repository has been archived by the owner on Oct 3, 2023. It is now read-only.

[Question] Why does this work without calling view.RegisterExporter from the OpenCensus library? #293

Open
mattwelke opened this issue Sep 4, 2021 · 2 comments

Comments

@mattwelke
Copy link

I was able to write a small Go program that uses OpenCensus to send metrics to Google Cloud Monitoring (formerly known as Stackdriver Monitoring) using this exporter.

I found it strange that the documentation at https://pkg.go.dev/contrib.go.opencensus.io/exporter/stackdriver#Exporter.StartMetricsExporter says:

Previously, it required registering exporter to export stats collected by opencensus. ... Now, it requires to call StartMetricsExporter() to export stats and metrics collected by opencensus.

It shows a code example that demonstrates that the "new way" to register the exporter is to use the following code:

exporter := stackdriver.NewExporter(stackdriver.Option{})
exporter.StartMetricsExporter()
defer exporter.StopMetricsExporter()

I was under the impression that view.RegisterExporter was the key to linking the OpenCensus views you register to the exporter(s) you choose to use. In the documentation about creating a custom exporter at https://opencensus.io/exporters/custom-exporter/go/metrics/ it says that you are supposed to use view.RegisterExporter to activate the custom exporter you write. This also reinforces the idea to me that view.RegisterExporter is important.

Why does this work without doing this step? And if this is second way is the suggested way of doing it, why was it changed?

@mattwelke mattwelke changed the title [Question] Why can this be used without calling view.RegisterExporter? [Question] Why does this work without calling view.RegisterExporter from the OpenCensus library? Sep 4, 2021
@dashpole
Copy link
Contributor

dashpole commented Sep 7, 2021

Unfortunately, the change that added the functions (and description), #121, doesn't have any details on why having Start and Stop functions is preferable to registering the exporter with a View. The authors of the change have moved on.

The stackdriver view Exporter does look a bit more complicated than the IntervalReader. The view Exporter has to aggregate multiple ExportView calls with a bundler, whereas the IntervalReader just exports on an interval.

@mattwelke
Copy link
Author

mattwelke commented Sep 7, 2021

I see. I don't know about IntervalReader or bundler or anything like that. I was just using OpenCensus according to its public documentation without worrying about how it's implemented. I was noticing this pattern of registering exporters to the views. I used it in production with Stackdriver and Prometheus exporters for a while.

I'm not sure if this is related but I noticed that when it came to overriding the reporting interval, if I did it on the view, it had no effect. I wanted to change it from its default of every 1 minute to every 5 minutes instead to save costs. I tried setting the reporting interval on the Stackdriver exporter and this did work. I reported this a while ago in census-instrumentation/opencensus-go#1153.

EDIT:

Actually, when I check that issue again, I notice that I wasn't able to reproduce my problem from my app in production. In a minimal example, setting the reporting interval while registering views did work. My takeaway from this is that there might be an issue with setting a reporting interval depending on how you happened to wire everything up, now that it's evident to me that there are multiple ways to wire this up and get data in Google Cloud Monitoring.

If you did into the issues linked to in that issue, you go down an interesting rabbit hole where they talk more about why view.RegisterExporter shouldn't be used, and they talk about knowing that a lot of users still do it this way (#193). I'm not sure what to make of it yet, but at least it means people encountering this can do some reading if they're feeling adventurous. :P

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants