indeedeng
recordExecutionTime doesn't convert from milliseconds to seconds
I'm using this library and I need to report runtimes to datadog. The readme claims that passing in long timeInMs will get converted to fractional seconds. From using the library and reading the source, it looks like this is not the case (this is however the case in the tim-group repo https://github.com/tim-group/java-statsd-client). If this could be fixed that would be ideal, but for the time being the specification in the readme should be updated. Thank You.
My use case:
Instant start = Instant.now();
... operations ...
Main.statsD.time("runtime", Duration.between(start, Instant.now()).toMillis());
My datadog graph shows runtime in the range of 13 seconds, but this operation is used in a web environment and server response is ~25 ms. Thus, 13 ms makes much more sense.
ok, please correct me if I'm wrong. When I look at the datadog graphs produced by the data, the graphs don't show "seconds", they just show the numbers.
So I'm just going to fix the readme, since we don't convert the value to seconds any more.
Ovesh, yes the graphs don't show units. That is all fine and dandy if all of the the times you report to datadog come from code written in Java using your library. Just as your readme states, the statsd client is expecting run times in fractional seconds, so if you don't change your library, well, it's now not compliant with any other platform. We for instance also have python code reporting times. Now to plot metrics from both sources, I have to remember to transform the Java one to be in the same units.
I hope you can see that this isn't a laziness issue, it's a cross platform compliance issue.
hmmmm ok, I see what you mean. Just to clarify, other APIs expect the value passed to be in seconds? or you also pass in the value in millis, and the api implementation converts it for you?
In the Python library datadog maintains, a method decorator allows methods to be timed. Those metrics are reported in the interface as fractional seconds.
Not sure what the specifics of it are, but it seems as though that's the decided upon standard for runtime metrics.
I'm going to handle this, but it's relatively low priority, so it might take some time.