search

cactus / go-camo

A secure image proxy server
MIT License
254 stars 48 forks source link

Use Prometheus for stats #33

Closed SuperQ closed 5 years ago

SuperQ commented 5 years ago

Feature request

Rather than build a custom stats module, it would be useful to implement metrics with Prometheus client_golang.

jacobbednarz commented 5 years ago

I’ve been working on some statsd integration for our use case (on an internal fork) and I’ve been wondering if we instead need a generic interface for emitting metrics and then on boot, determine which adapter to use. For example: go-camo ... -stats-adapter=statsd or go-camo ... -stats-adapter=prometheus. I’m not sure how easy or even possible this will be due to the differences in approaches.

Thoughts or preferences here @cactus?

SuperQ commented 5 years ago

I personally don't have a use for statsd because the non-tagged/labeled data is harder to work with. It's also a lot less intrusive to add Prometheus metrics because the library doesn't emit anything at each request. The library is pretty efficient. For example, the histogram observations take about 25 cpu nanoseconds.

dropwhile commented 5 years ago

@jacobbednarz hmm. Having multiple mechanisms for stat output would complicate the code a bit. I'll have to think it over.

As far as statsd vs prometheus, one aspect of statsd that I do happen to prefer, is that percentile calculations occur on the server side. Prometheus uses locally calculated bucketized historgrams, which do lose granularity. With statsd you can also use statsd_exporter, as a means to transition between systems. I'm not aware of anything that goes from prometheus to statsd though.

That said, I think prometheus is more in line with the current /status type endpoint, and as such, would presumably be a pretty easy transition for folks.