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

Library Architecture Patterns #15

Open
lswith opened this issue Jun 28, 2018 · 2 comments
Open

Library Architecture Patterns #15

lswith opened this issue Jun 28, 2018 · 2 comments

Comments

@lswith
Copy link

lswith commented Jun 28, 2018

I am currently using this library and I quite enjoy it's use. I think that for our needs though a few interesting concepts may need to be addressed.

In Prometheus Client libraries, it seems that they provide 2 main bits of functionality regardless:

  • the ability to add metrics by simply importing the lib
  • the ability to start the webserver to export the metrics (they've moved towards text based only now)

This library requires the plug exporter library and I wonder if that should simply be included in this library?

Other concerns I have are around which application should "setup" the Metrics. I see that if I wish to create an instrumenter, I need to call the setup in my application boot loader. This seems like it should be handled by the prometheus client library.

I would love to hear your thoughts on this.

@deadtrickster
Copy link
Owner

All automagic stuff like registering by simply importing is dependent on what "import" means for particular language/runtime. Thanks to interactive/embedded modes differences we generally can't reliably auto discover code (because we can be running in interactive mode and not everything was loaded yet). The only way to automatically declare metrics that works so far assumes you have a modules that's used as a callback and you declare metrics using attributes and have on_load callback autogenerated for you. Of course you can write on_load callback manually.

There is a reason why the library doesn't have http endpoint included. Too many webservers :-). And not all prometheus_ex users also use plugs.

@lswith
Copy link
Author

lswith commented Jun 28, 2018

what about a behaviour to implement? Then the prometheus library would simply be the instrumenter's supervisor and setup handler.

Similar to an Ecto.Repo behaviour ?

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