Closed mdelaurentis closed 7 years ago
Using "metrics" definitely makes more sense than "stats."
I think the document does a good job explaining each of the fields.
As for the distinction between Timers and Counters, I'm wondering if we should be deferring this functionality (and also the terminology) to a library. As an example, I've used Dropwizard in a few projects and found it to be an excellent library. A quick search yielded a Python compatible library here.
I think using this library would take 3 steps:
Reporter
. Something like a JSON + stdout Reporter. This could live in singer-python.MetricsRegistry
which is assigned our Reporter
Counter
, Histogram
, Meter
, Timer
, Gauge
, CallbackGauge
, SimpleGauge
.I think a pattern like this would give us a few benefits:
What do you think?
Thanks very much for the feedback @KAllan357. I agree that "metrics" makes more sense than "stats". I'll change it in the best practices guide.
Regarding the use of pyformance, I think we should evaluate it on a Tap. I'd like to see if we can get the same output as singer-python, and then see how the code looks if we use it. If we can get similar output and it's easy to use, I'm open to it.
I've been adding experimental metrics logging to singer-python and a few taps. I'd like to add a best practice recommendation for logging metrics from Taps. I would really appreciate feedback on this best practice recommendation and the singer-python changes. Below are links to diffs for a few taps that use the new singer-python stats utilities, so you can see how the implementation would work in practice.
I'm particularly interested in answering feedback in the following areas: