Library Architecture Patterns

[lswith]

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]

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]

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 ?