converts timers to milliseconds as statsd timers explicitly say to re…

[ETetzlaff]

Statsd docs specify timers should be reported in milliseconds. This converts the time reportings to milliseconds for finer granularity.

[minond]

The harness-protobuf-nats gem will take a given delay/duration value and pass it as is for server metrics (https://github.com/mxenabled/harness-protobuf-nats/blob/1347976770d809ce190e5a44cea97015f1f58b4b/lib/harness/protobuf/nats.rb#L17). The problem is that this delay is in seconds,

protobuf-nats/lib/protobuf/nats/server.rb

Lines 49 to 55 in 5058cb9

	enqueued_at = ::Time.now
	was_enqueued = thread_pool.push do
	begin
	# Instrument the thread pool time-to-execute duration.
	processed_at = ::Time.now
	::ActiveSupport::Notifications.instrument("server.thread_pool_execution_delay.protobuf-nats",
	(processed_at - enqueued_at))

But it should be in milliseconds according to the gem we're using, https://github.com/reinh/statsd/blob/master/lib/statsd.rb#L392-L402

Right now this is an issue with the protobuf-nats.server.thread_pool_execution_delay metric and the protobuf-nats.server.request_duration metric. The client.request_duration.protobuf-nats metric is able to get around this since it will use an ::ActiveSupport::Notifications::Event and get the duration using Event#duration, which works on milliseconds (https://api.rubyonrails.org/classes/ActiveSupport/Notifications/Event.html#method-i-duration). Other gems, like harness-action_subscriber, do something similar.

[film42]

Released as v0.10.1.