Why is Metrics::Instruments a module?

[eric]

I'm having trouble understanding why Metrics::Agent is a class but Metrics::Instruments is a module — it prevents more than one instance of Metrics::Agent from being possible.

[johnewart]

Architecturally it was designed that your application would have a metrics agent that was where all your instruments would be registered. This agent then exports data either pulling via HTTP or pushing to something like Ganglia (which I have a component for actually that I need to add here...).

I'm open to changes, but why would you want to have more than one instance of an agent rather than just one agent with multiple exporters working their magic?

[eric]

The biggest confusion I had was between the fact that Metrics::Agent is a class and thus can have multiple instances created, but under the covers it is still referencing the same set of instruments.

I have a general assumption that if I'm creating an instance of something it will not be doing global things behind the curtain.

As to the question if it makes sense to have a single instance that everyone in a given process uses? I could see doing something similar to what the redis gem does with a Redis.current instance that you can reference (and is lazily created when first accessed) to give everyone a place to go to get a metrics instance if they aren't interested in doing something crazy (like have more than one instance).

One of the big reasons why I could see wanting to have multiple Agents in a process is if a library wanted to use ruby-metrics for their own internal metrics that are sent to their own servers (like if hoptoad wanted to add some internal metrics to how much things happen in their code and have them sent back to hoptoad, not to you), it would be nice to allow it.

[swistaczek]

@eric I totally agree with you 👍