Add multiplier option to prometheus helper #10994
Conversation
Prometheus histograms can contain buckets with keys in decimal representation. They create events with dots in the field names, what can be problematic when stored in Elasticsearch as they will create sub-objects. Add a new option to allow to store these keys in different units, so precission is kept but in a different order of magnitude.
jsoriano
added
enhancement
module
review
Metricbeat
|
jenkins, test this again please |
|
Hello, any update on this? |
| } | ||
|
|
||
| // Process will multiply the bucket labels if it is an histogram with numeric labels | ||
| func (o opMultiplyBuckets) Process(field string, value interface{}, labels common.MapStr) (string, interface{}, common.MapStr) { |
There was a problem hiding this comment.
What's the reason for not using pointers here?
There was a problem hiding this comment.
Good question, I didn't think about this, I just followed what was being done for other options.
In any case I wouldn't change it now, we can consider doing it for all options in the future.
| @@ -57,6 +57,13 @@ func OpLowercaseValue() MetricOption { | |||
| return opLowercaseValue{} | |||
| } | |||
|
|
|||
| // OpMultiplyBuckets multiplies bucket labels in histograms, useful to change units | |||
| func OpMultiplyBuckets(multiplier float64) MetricOption { | |||
There was a problem hiding this comment.
I'd call this NewOpMultiplyBucketsOption unless we have some internal convention for this
There was a problem hiding this comment.
I don't have an strong opinion on this but yes, I am following the naming schemas used here.
Take into account that they are not so bad as they are used as options in prometheus metrics:
Metrics: map[string]MetricMap{
"histogram_decimal_metric": Metric("histogram.metric", OpMultiplyBuckets(1000))
}
|
Failing test is not related, and green in travis, merging. |
|
hey @jsoriano, trying to update #10585 two small questions occurred to me:
Sorry for not finding earlier. 😞 |
Prometheus histograms can contain buckets with keys in decimal
representation. They create events with dots in the field names, what
can be problematic when stored in Elasticsearch as they will create
sub-objects.
Add a new option to allow to store these keys in different units, so
precission is kept but in a different order of magnitude.