wvanbergen
commented
4 years ago The goal has always been that you can configure StatsD fully with environment variables, so that you don't have to use initializers, etc. In the past we used this to easily configure StatsD properly for all our heroku apps, now we can use this for cloud platform apps.
The Environment class/singleton does not hold configuration. Rather, it parses configuration from ENV. Because the logic is more complicated than simply reading environment variables, this has been extracted into a separate module.
- For the legacy client, some configuration values are set on the singleton (e.g.
StatsD.default_sample_rate. This is done in theEnvironment.setup. Some other configuration is used to instantiate the backend that will be used as the singleton's backend (StatsD.backend) - For the new
Clientimplementation, the client instance holds all the configuration they need to operate. I would still like to be able to construct a client based on what is in the environment, and use that as the client that we use to delegate metric calls on the singleton module to (e.g.StatsD.increment).
I prefer using a class rather than a singleton for this because it easier to test (no need to stub values in ENV, etc).
I agree that the implementation is a bit messy because it serves both the legacy client as well as the new client, and tries to be backwards compatible. Once we drop the legacy client, we can clean this class up.
StatsD::Instrument::Environmenta class rather than a singleton module, but make sure thatenvironmentanddefault_backendstill work as singleton methods.StatsD::Instrument::Environment#default_clientto instantiate a new Client based on environment variables.STATSD_PREFIXandSTATSD_DEFAULT_TAGS. The goal is that people should not configure StatsD in code, but completely using environment variables. If that doesn't work for your use case, we recommend that people instantiate their own client and not use the default client.