Allow overriding metrics type about statsd_exporter HOT 10 CLOSED

I'm not sure this should be an issue / feature for the statsd exporter. Fixing the application is the right thing to do here. I vote to close this issue until there are multiple users having this need and can't fix their app for some understandable reason.

from statsd_exporter.

@marcosnils would that solve your problem? You could use mapping configuration to coerce these metrics into gauges, even if they're sent as counters. If you want to tackle this, please do, and let me know if you need any pointers.

from statsd_exporter.

@matthiasr I'm not sure if this will solve the problem. As you already know, Gauges are used for values that go up & down. In this particular case, the value will never go down, so I can't image how to graph something like rate(http_total_count[5m]) with a gauge metric.

from statsd_exporter.

Technically, that's true – in practice Prometheus does not enforce types, and you can totally take the rate of a "gauge". The result won't be useful if the gauge ever goes down without resetting to zero, but otherwise that would work.

from statsd_exporter.

Makes sense. I guess this fix could work then. I'll try to give it a shot later today.

from statsd_exporter.

Of course, fixing the source of the incorrect metrics would always be preferrable to any overriding – different from the SNMP case, there's actually a reasonable chance for anything that emits to statsd.

In your case, that could mean emitting the metrics as gauges, or actually emitting the counter deltas as the statsd protocol demands.

from statsd_exporter.

@matthiasr / @grobie FTR: I'm running into the very same issue.

We're using statsite. It listens for statsd metrics, spawns a subprocess (the "sink") and writes them to its stdin which then sends the metrics over to graphite aswell as the statsd exporter. This is the statsite ASCII protocol:

key|val|timestamp\n
[...]

As you can see the type information gets lost during the handover to the subprocess. It would be really handy if i'd be able to map the types in the statsd exporter.

from statsd_exporter.

That's … a completely different protocol? Looking at the statsite documentation the sink protocol is distinct from the statsd protocol. The statsd exporter should accept the same input as statsite (since they both stand in for the OG statsd), but the statsite output is different. If you want to emit statsd metrics from statsite, it seems like you need a statsd sink that translates back into the statsd protocol first?

from statsd_exporter.

We translate it back to statsd (we've essentially built a split-sink - graphite aswell as statsd-exporter) - without the type information tho. It would be handy to be able to overwrite the types (temporarily) for the migration process.

from statsd_exporter.

In that case I would suggest you restore the types in your sink? Given statsite/statsd already pre-aggregates events, these are all gauges anyway?

If it's for a migration, I would not sweat over types too much. There is little practical difference between the counter, gauge, and untyped metric types – and summary/histogram only really work if you are sending raw events to the exporter.

from statsd_exporter.