This adds an opt-in cardinality checker to the statsd client.
It will report a gauge of all the unique stats key that it
has seen locally within the process.
When deployed in production you would expect this to
increase over time and then plateau.
This stats allows you to detect the cardinality of the stats
you are publishing to statsd. If this increases sharply or
exponentially then you know that you might be publishing
unique keys (or uuids) to statsd.
Generaly you want to keep the cardinality to some sensible
finite number.
This can be used in production to alert on leaks in your
statsd key space.
As an added bonus it counts keys in memory; this means you
can REPL into your process and inspect the current list
of keys on the statsdClient instance.
This adds an opt-in cardinality checker to the statsd client.
It will report a gauge of all the unique stats key that it has seen locally within the process.
When deployed in production you would expect this to increase over time and then plateau.
This stats allows you to detect the cardinality of the stats you are publishing to statsd. If this increases sharply or exponentially then you know that you might be publishing unique keys (or uuids) to statsd.
Generaly you want to keep the cardinality to some sensible finite number.
This can be used in production to alert on leaks in your statsd key space.
As an added bonus it counts keys in memory; this means you can REPL into your process and inspect the current list of keys on the
statsdClient
instance.r: @Matt-Esch @markyen @robskillington