-
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/transform] Add metrics data model #9719
[processor/transform] Add metrics data model #9719
Conversation
Open Questions: |
/cc @anuraaga |
Handled via the descriptor. can access via |
I think we'll have to handle exemplars and quartile_values either via a new transformContext so that they can have their own |
Added tests for NumberDataPoint, HistogramDataPoint, ExponentialHistogramDataPoint, SummaryDataPoint, and Descriptor. I did not add tests for Resource or InstrumentationScope since the code is the same as traces and logs, which have tests, and we are planning to refactor both into a single place. |
@anuraaga ready for official review |
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.
Thanks! Just suggestion on the new method on TransformContext
@open-telemetry/collector-contrib-approvers please review. |
Wired this up into a full processor locally to test out a use case we're looking for (resource attribute copied down to metric attribute) and it worked perfectly. 👍 |
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
@TylerHelmuth should this have a changelog entry? |
I didn't add one bc #9271 didn't have one. A changelog entry was added when logs were wired up (#9368) |
Description:
Adds the metrics data model to the transform process. Wiring up the processor to the metrics pipeline will be a different PR. Similar to #9271, logic has been stolen from traces and logs. Similar logic will be broken out later. Within metrics.go itself there is a lot of duplicate logic (especially with the switch statement). I am hoping generics can help with this in the future.
Link to tracking Issue:
#8252
Testing:
Documentation: