Allow specifying tags for metrics

[ocharles]

OpenTSDB - the time series database used by bosun - uses a different naming convention than EKG. Metrics have an arbitrary name, but they also have a list of key-value pairs (tags). The idea is that you can now have more general metrics such as http.response_time, and then tag data points with specific information such as route=/api/list-foos.

I wonder if EKG should support such a thing, or if I should add support for "post-processing" metrics to ekg-bosun - postProcess :: Name -> (Name, [Tag]), or something to that effect.

Thoughts?

[tibbe]

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 and strings) can be done in a type safe manner i.e. once the counter is created calling inc on that counter requires that you pass N dimension values of the right type. Here's how to not do it:

data Dim = T Text | I Int
newCounter :: [Dim] -> IO Counter
inc :: Counter -> [Dim] -> IO ()

I was thinking of using e.g. a phantom type to track the dimensions for a given counter by using a more untyped representation internally. Needs some thought.

[ocharles]

Interesting idea. Keep me posted!

[lucasdicioccio]

Just saw this issue, was replying on #12 (comment) that I've started a patch.
I'll be updating only this issue starting from now.

I'll fix ekg-json soon (very likely adding a key to the ToJSON instance), then ekg will take me more work (in particular, the HTML+JS rendering).

Then, we can imagine a typeful API using typelevel strings or a typeclass to add a variable number of arguments. This typeful API could live in another package.

I'm still unsure whether we should add a hashmap-like interface to "manage" counters for points using new dimensional breakdowns. In particular, there's a risk to have an unbounded number of counters growth if library users do not pay attention + I don't like exposing a lookupOrCreate function when I often use counters in tight-loops on-the-fly -- imho, such a lookupOrCreate function should live in another package.