expose additional StatsD methods in toolkit metrics

[EvaLok]

stuff like count, decrement and so might be handy for more accurate metrics

[MaikelH]

We should definitely be looking into exposing more options. We should make a list of all the different methods and see what we can implement. I think most of the stuff should be pretty easy to implement.

[EvaLok]

yep i think so too; we could also consider adding a "native" (or something like this) export on the metrics so that library-specific-but-not-universal methods can be accessed. something like:

var metrics = require('microservice-toolkit').metrics.native;

metrics.someRandomMethod('stuff');

what do you think?

[EvaLok]

..of course i guess this only applies once we want to use other libraries for metrics

[MaikelH]

Exposing the internal metrics could be dangerous, since it can easily break. The underlying library can be changed or a different metrics back-end is loaded and all your code breaks.

[EvaLok]

that certainly could happen; i was more thinking that it might be a nice way to stay as unopinionated as possible, since presumably if someone wants access to the native methods, they would be locking in the toolkit version and aware enough of their configuration situation that this wouldn't be a problem. in any case, even if we were to decide to do it, it's definitely not high priority compared to simply exposing some common methods, just wanted to consider it ;)