-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[processor/metricstransformprocessor]: Support median aggregation type #33655
[processor/metricstransformprocessor]: Support median aggregation type #33655
Conversation
4d0ee19
to
33c5372
Compare
268ed54
to
8eabf28
Compare
**Description:** <Describe what has changed.> - duplicated and enhanced aggregation business logic (with median function) for common usage in follow-up tickets - tests **Link to tracking Issue:** #16224 **Follow-ups:** - #33655 - #33334 - #33423 --------- Signed-off-by: odubajDT <[email protected]>
def6d9f
to
451b941
Compare
ac49460
to
88b7084
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me based on the fact that the tests have been minimally changed.
processor/metricstransformprocessor/metrics_transform_processor_otlp.go
Outdated
Show resolved
Hide resolved
@dmitryax Could you take a look? This bridges what I believe is the final gap between the metrics transform processor and transform processor, and will let us confidently merge #33334. I'll do a review after this to confirm, but I think once we know there is parity between the two, we can start pointing users to the transform processor as a meaningful replacement. |
9587143
to
a97a4c2
Compare
Signed-off-by: odubajDT <[email protected]>
…r_otlp.go Co-authored-by: Evan Bradley <[email protected]>
a97a4c2
to
e9a6f45
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
**Description:** <Describe what has changed.> It is a valid use case to aggregate against an empty label set, which will functionally clear all attributes. This behaviour was removed in #33655, which simplified the check to `len() == 0`, which covers the case of the label set being `nil` and having 0 elements as the same scenario. However, these are not the same scenario and have different meanings. This PR reintroduces the original behaviour, but in a more efficient way by recognizing a label set with 0 elements and clearing the attributes, which would be the logical conclusion after running the filter anyway. **Link to tracking Issue:** #34430 **Testing:** <Describe what testing was performed and which tests were added.> **Documentation:** <Describe the documentation added.> --------- Co-authored-by: Tyler Helmuth <[email protected]>
…metry#35006) **Description:** <Describe what has changed.> It is a valid use case to aggregate against an empty label set, which will functionally clear all attributes. This behaviour was removed in open-telemetry#33655, which simplified the check to `len() == 0`, which covers the case of the label set being `nil` and having 0 elements as the same scenario. However, these are not the same scenario and have different meanings. This PR reintroduces the original behaviour, but in a more efficient way by recognizing a label set with 0 elements and clearing the attributes, which would be the logical conclusion after running the filter anyway. **Link to tracking Issue:** open-telemetry#34430 **Testing:** <Describe what testing was performed and which tests were added.> **Documentation:** <Describe the documentation added.> --------- Co-authored-by: Tyler Helmuth <[email protected]>
Description:
interval/core
median
aggregation typeLink to tracking Issue: #16224
Depends on #33669