Implement logic for storing fields that are neither dimensions nor metrics (aka tags)#87929
Conversation
|
elasticsearch-ci/part-2 is failing at the moment for a mapping issue involving IPv4 addresses which are handled as keywords. The following line |
|
@elasticmachine run elasticsearch-ci/part-2 |
csoulios
left a comment
There was a problem hiding this comment.
Thanks for iterating on this.
I left some more comments.
| - skip: | ||
| version: " - 8.2.99" | ||
| version: " - 8.3.99" | ||
| reason: tsdb indexing changed in 8.3.0 |
There was a problem hiding this comment.
reason should be something like "rollup: labels support added in 8.4.0"
| if (validTypes.contains(value.getClass()) == false) { | ||
| throw new IllegalArgumentException( | ||
| "Expected [" + VALID_TYPES + "] for field [" + field + "], " + "got [" + value.getClass() + "]" | ||
| "Expected [" + VALID_METRIC_TYPES + "] for field [" + field + "], " + "got [" + value.getClass() + "]" |
There was a problem hiding this comment.
Should VALID_METRIC_TYPES be validTypes?
x-pack/plugin/rollup/src/main/java/org/elasticsearch/xpack/rollup/v2/RollupShardIndexer.java
Show resolved
Hide resolved
| final Object[] value = fieldValues.apply(docValueCount); | ||
| if (metricFieldProducers.containsKey(field)) { | ||
| // TODO: missing support for array metrics | ||
| collectMetric(field, value[0]); |
There was a problem hiding this comment.
About the TODO: missing support for array metrics comment here. Is this something you plan to add in this PR or in a following PR?
There was a problem hiding this comment.
Not really, because I think that needs to decide first how do we handle that which I don't have any idea at the moment.
There was a problem hiding this comment.
I think it should work in the same way as aggregations work on multi-value fields.
| final MappedFieldType fieldType = mapperService.mappingLookup().getFieldType(field); | ||
| return fieldType != null | ||
| && (timestampField.equals(field) == false) | ||
| && (fieldType.isAggregatable()) |
There was a problem hiding this comment.
Why must a label field be aggregatable?
There was a problem hiding this comment.
This is basically to avoid fields of type text which is not aggregatable...while it would work with fields of type keyword which are aggregatable.
There was a problem hiding this comment.
If I remove that condition the tests result in an errors saying something like "you need to use aggregatable fields or use <some API I don't remember> to support non-aggregatable fields
There was a problem hiding this comment.
cool thanks for the explanation. I had missed that
There was a problem hiding this comment.
This actually means that we cannot have a text field as label?
|
@elasticmachine update branch |
|
@elasticmachine update branch |
|
merge conflict between base and head |
csoulios
left a comment
There was a problem hiding this comment.
LGTM!
Thank you for iterating on this
Are we still waiting for something before being able to merge or can I proceed? |
Please go ahead and merge it. We have identified 2 TODO tasks that can be implemented in follow-up PRs:
|
I will create two tasks in #74660 to track them. |
We want labels to be collected storing just the latest value
when aggregating documents in a rollup index. This means
labels will behave similarly to counter metrics.