Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redirect data to Google Cloud Monitoring #73

Open
marceloclp opened this issue Sep 7, 2020 · 2 comments
Open

Redirect data to Google Cloud Monitoring #73

marceloclp opened this issue Sep 7, 2020 · 2 comments

Comments

@marceloclp
Copy link

Is there a way to redirect the data to another service such as Google Cloud Monitoring?

I was thinking of using OpenCensus to transform the data to the correct format, but I am unsure how to pipe the data to another service.

@dm03514
Copy link
Collaborator

dm03514 commented Sep 7, 2020

Hello! @marceloclp . Are you referring to the metric data or the tracing data?

The metric based data currently leverages OpenCensus! The tracing data currently leverages OpenTracing.

ValueStream's main.go entry point currently is hardcoded to use the OpenCensus prometheus exporter but it should be trivial to update it to switch on a CLI flag or envvar to initialize the Stackdriver metric exporter.

https://github.com/ImpactInsights/valuestream/blob/master/main.go#L165

Instead of initializing the prometheus exporter directly like below:

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

		if err != nil {
			return fmt.Errorf("failed to create the Prometheus exporter: %v", err)
		}

		r.Handle("/metrics", exporter)

we could have a generic exporter, which takes the CLI flags and the current router and returns an exporter interface and an error object:

exporter, err := initializeExporter(ctx, c, r)

if err != nil {
  return fmt.Errorf("failed to initialze metric exporter: %v", err)
}

And initializeExporter could like like:

func initializeExporter(context.Context, *cli.Contxt, *mux.Router) (io.Closer, error)

The function could return a closer since the different exporters may need to flush and stop. For example the stackdriver looks like it needs to both flush and stop:

	defer sd.Flush()
	
	// Start the metrics exporter
	sd.StartMetricsExporter()
	defer sd.StopMetricsExporter()

@marceloclp
Copy link
Author

Wow, thanks for the detailed explanation @dm03514 ! Yes, this is exactly what I was looking for and it really simplifies my original plan!

Is there a plan to officially support different exporters?

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

No branches or pull requests

2 participants