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

Remove Deprecated Prometheus - Use OpenCensus Instead #194

Open
marwan-at-work opened this issue Feb 9, 2019 · 1 comment
Open

Remove Deprecated Prometheus - Use OpenCensus Instead #194

marwan-at-work opened this issue Feb 9, 2019 · 1 comment

Comments

@marwan-at-work
Copy link
Contributor

With OpenCensus becoming a default, and since it supports prometheus as well as a few other backends, I think there's no reason from calling the Prometheus client directly in places such as https://github.com/NYTimes/gizmo/blob/master/server/simple_server.go#L103
and https://github.com/NYTimes/gizmo/blob/master/server/simple_server.go#L122
where both function calls are deprecated according to prometheus docs.

Here are a few options:

  1. Let the user just call gcputil.RegisterStackDriver() themselves, so they can be free to choose other backends if they need to.
  2. Let SimpleServer call gcputil.RegisterStackDriver() internally, but we should probably provide a new server.Config option such as SkipMonitoring or EnableMonitoring depending on the kind of default behavior we want yet still letting the user to be able to opt out of it if they have other needs.
  3. We can have the user pass in an opencensus.Exporter interface and just register it with OpenCensus on Init

Personally, I prefer option 3, and 1 the most

@jprobinson
Copy link
Contributor

I'm in for hooking Prometheus into the kit server as well. Following along with my comments in the gcputil branch, I wonder if we can just have that package return the exporters we need to register.

Internally, I wonder if that new package could be something like observe.NewOCExporter(...) and it would scan the environment (or some simple config?) to determine which exporters to initiate and respond with them. This could check for Prom configs, init that if they exist then fall back to checking GCP creds/Stackdriver options.

I like the idea of (3) too, though: Allow users to pass a custom exporter on their own. I just wonder if thats a use case we need.

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