what happens if the event has dogstatsd tags attached? I think we need to keep separate sets for each of them.

not familiar with dogstatsd, but that makes sense. Are those stored in Event.Labels()?

yes

I'm not sure about handling the flush in-line with incoming statsd events. It's fundamentally different (internal, not user-generated. Would it make sense to break it out into its own loop, or does that get us into locking/mutex hell?

if we keep it inline, please add a comment explaining why it's here

I'm not sure how much locking/mutex work there would be, I'm not super familiar with your code. This mechanism let me completely avoid the question. :)

you would need to mutex-protect all the map accesses. it's fine this way, but I think we can't safely circle back into handleEvent because that would cause double-mapping.

it's customary in Go to collapse these lines to

if _, ok := store[event.Value()]; !ok {
	store[event.Value()] = true
}

so that it can go out of scope when no longer needed.

I also see the variable usually called ok – you're calling it both have and found, I'd rather be consistent with those where possible.

Did it that way to avoid aliasing. Is aliasing generally not frowned on in Go code?

it's probably better not to – although my instinct is that if you run into aliasing, you're nesting the code too deeply. One thing that took me a while to get used to in Go style is that we prefer

if … {
  … do stuff …
  return
}
… do other stuff …

rather than using an else. In most cases this means there is only one "ok" to work with. I don't see how to do that neatly here though, so I'm okay with leaving the names as they are.

won't this cause strange side effects? we allow matching on the metric type, so if I have a mapping that explicitly only applies to sets, it won't affect this event, but others will.

One thing you could to, instead of sending a GaugeEvent through the event handling again, is to maintain and set prometheus Gauge metrics directly, based on the mapping of the set event.

I found myself duplicating much of the handleEvent function (to get mapping, help, labels), code which I don't completely understand yet. Doing it this way let me avoid the duplication.

As far as I'm concerned, a set is a type of gauge; anything you'd want to do to a gauge (mapping, histograms as discussed, et cetera) probably would be useful on a set. So I also rationalize my laziness that way. It'd have to be called out in the documentation if so.

but these have all been already determined when mapping the set event. the mappings act on statsd types, not Prometheus types, so even if the output is a gauge we cannot treat |s events as the same.

I think the correct way is to preserve whatever is needed from the first event that is handled, and then get the Prometheus metric objects the same way case *GaugeEvent does.