countersshould get you what you’re after.
After running the docker image from https://hub.docker.com/r/statsd/statsd,
I do see,
24 Mar 09:30:40 -  reading config file: config.js
24 Mar 09:30:40 - server is up INFO
but i don't see anything is running in localhost:8125
Statsd timing is designed for something like: emitting the time it took for a HTTP endpoint to return a response. Those stats can be produced at any time and so statsd will aggregate them into blocks and flush at the pre-determined interval to help normalise the data. Your data might look like:
If you've already got the timing (ie: http response time) and the time you want it to land in the database, ie data that looks like:
Then I'd suggest just tossing it straight into influx yourself and ignoring statsd as you're not really getting any benefit from using statsd.
Hey sorry it got a bit late last night and I think I misread a few things.
The timings are already aggregated when they're sent to statsd and they occur with irregular intervals.
This is really the important bit, statsd lets you hand in a timing duration into the stat, and assumes the timestamp to store that against is whatever statsd understands the current time to be on the system. So if you want to pass it a timing data + a specific timestamp you won't be able to do that.
If you're just passing it the timing data (ie, producing these stats in real time when a customer service interaction ends) and tossing it straight to statsd then you're all good and statsd can help you. Just ignore your own timestamps, pass it the duration and it'll do everything for you.
It is possible to turn off various calculated stats for the timer metrics - you can use
calculatedTimerMetrics which is in the exampleConfig.js.