In the just-released riemann-java-client 0.0.6, riemann-clojure-client 0.0.6, riemann-ruby-client 0.0.8, and the upcoming riemann 0.1.4 (presently in master), Riemann will support two new types of metrics for events.

https://github.com/aphyr/riemann-java-client/blob/master/src/main/proto/riemann/proto.proto#L24

# signed 64-bit integers (variable-width-encoded)
optional sint64 metric_sint64 = 13;
# double-precision IEEE 754 floats
optional double metric_d = 14;

Events still have only a single logical metric; this change simply allows the protocol to represent a broader range of numbers. Clients should prefer metric_sint64 for all integer values from -2^63 to 2^63 - 1, and prefer metric_d for double-precision floats. Clients should also write metric_f wherever possible and fall back to reading metric_f, for compatibility with older versions of Riemann.

Here’s how the Ruby client does it. Note that Ruby’s Float is actually a double.

def metric
  metric_d ||
    metric_sint64 ||
    metric_f
end

def metric=(m)
  if Integer === m and (-(2**63)...2**63) === m
    # Long
    self.metric_sint64 = m
    self.metric_f = m.to_f
  else
    self.metric_d = m.to_f
    self.metric_f = m.to_f
  end
end

Javascript has only one numeric type: double-precision IEE754 floats (sort of). Riemann uses Cheshire and will emit JSON numbers which may exceed the scale or resolution of a JS VM, e.g.:

{"metric":12345678901234567890,"time":"1970-01-01T00:00:01.000Z"}

… which in V8 will be parsed as the number 12345678901234567000. Larger values may become +/- Infinity when parsed. Rationals are serialized as decimals.

Since most JS clients are engaged in visualization, loss of precision seems preferable to emitting JSON strings (e.g. 123 -> “123”) and forcing clients to use arbitrary-precision bignum libraries with custom operators. I’d like your feedback. :)