Closed deadtrickster closed 8 years ago
Is the something inherently wrong with regex matches? I'm very new to Prometheus. Thanks for all your work on this.
Not 'wrong'! Maybe it's just me not liking them :-) (they are definitely slower and require more thought). Anyway, status_code
can dramatically increase storage usage. While this is highly use-case dependent (prometheus can handle millions of TS after all) it looks really verbose. I want to stress I don't want to remove status_code
but introduce status_class
(informational|success|redirection|client-error|server-error) as default.
Right. :+1: for status_class
. Those values sound good to me too.
Maybe we should do the configuration in elli_prometheus instead. I could imagine an edge case where someone is using another Prometheus plugin of sorts and the configuration conflicts.
the configuration conflicts
this is why I'm namespacing settings under elli_exporter
.
Bah, right. Ok this looks good to me then. I'm mobile atm.
So do you want me to implement status_class
? I feel like I want it in prometheus-plugs too and therefore I'll just add it as a helper to prometheus.erl itself (and default duration buckets too).
That sounds good to me!
Hey!
This PR incorporates #1 and #2. It also allows configurable scrape path, format and duration buckets. I implemented configuration based on prometheus application environment. It's probably not idiomatic from elli's point of view so please do let me know if this is not acceptable.
I would also like to note that
status_code
label can lead to 'overflow'. While set of values of this label is definitely finite it's still can be large. Prometheus treats each label set as separate time series. Likely there is also usability issue - imagine you want to graph all successful replies then you have to use regex matches. So maybe introducestatus_class
label and makestatus_code
optional?