Johan Tibell

The `Value` type captures semantic information about the metric being monitoried: ```haskell data Value = Counter {-# UNPACK #-} !Int64 | Gauge {-# UNPACK #-} !Int64 | Label {-# UNPACK...

> the monotonically-increasing semantics of a counter shouldn't matter, because it's implementable in terms of a `gauge`. The distinction makes a difference to the consumer and is why statsd also...

This is in the plans but I haven't had time to work on it yet. I'd like a design where creating e.g. a counter indexed by N dimensions (e.g. integers...

ekg used to do this for its `getX` functions, but I changed it at some point and decided to let others add that kind of functionality on top of ekg....

@tfausak I don't know if I would go as strongly as "not allow", but at work we've found that all dynamically named metrics we're really just single metrics with dimension(s)....

Basically what @lucasdicioccio said. I imagine a new API in ekg-core, lets call it `System.Metrics.MultiDim.Counter` for the sake of this example. (None of this compiles as is, but hopefully gives...

It's not exposed because I want to be able to change the implementation (e.g. to add support for quantiles). However, I am open to adding e.g. `Binary` instances or explicit...

I think depending on binary is OK. If we don't want to commit to a specific library we could instead just offer: ```haskell encodeStats :: Stats -> ByteString decodeStats ::...

> Have you seen HdrHistogram? It's a preferred alternative to an ordinary histogram since it avoids coordinated omission. I have. Unfortunately I believe they suffer from the same problem as...

The main reason is that if you're guaranteed that a counter is non-decreasing, you can detect when a process you're monitoring crashes (because the counter would go backwards) and correct...