-
Notifications
You must be signed in to change notification settings - Fork 808
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
feat(proto): add @opentelemetry/otlp-transformer package with hand-rolled transformation #2746
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2746 +/- ##
=======================================
Coverage 93.19% 93.19%
=======================================
Files 157 157
Lines 5117 5117
Branches 1097 1097
=======================================
Hits 4769 4769
Misses 348 348 |
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 % nits.
Hi, sorry for disturbing, are there any plans to merge this in near future? I am concerned about #2675 |
Converting to draft while we wait on #2775 |
650d6ec
to
0243756
Compare
I think we have 2 final questions to resolve before merging this @open-telemetry/javascript-maintainers @open-telemetry/javascript-approvers
Right now I have it as
The return type of each serialization function depends on the field names in the proto which are unstable. For example, |
Marking as ready for review again as it is higher priority due to #2804 |
I agree that it shouldn't refer to proto directly and more to the protocol itself so i'm fine with
I'm not really sure but could we just have optional option that specify which proto version we encode to ? Once it get merged we could add a if that changes the generated representation ? |
I would prefer not to do that if possible. I don't want to commit to maintaining all proto versions in parallel forever. |
It sounds to me that the problem here is similar to the JSON representation of the OTLP protocol since the names of the fields/types have to be part of the stabilized API. Are there any roadmaps on the stabilization of JSON representation?
Did you forget to hit the button? The PR is still a draft. |
CI failure could be fixed by #2768 |
I don't personaly think another way to do this expect waiting for stabilization :/ |
I was thinking we could document in the tsdocs explicitly that we are generating protos of a certain version and that future minor versions may generate another version. |
We could also independently version the package because we know it will need to be versioned each time something like this happens |
This sounds very similar to the experimental packages in the repo to me. |
In the past we've had a requirement that stable packages don't depend on experimental packages, but maybe we can make a documented exception here in order to avoid leaking the implementation details of the OTLP transformation? One other option would be to make this package a |
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.
Overall LGTM, great work!
…json transformation
Sorry for force push i had the wrong email in the history |
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! 👍
const instrumentationLibraryMetrics = ilmEntry.value; | ||
if (instrumentationLibraryMetrics.length > 0) { | ||
const lib = instrumentationLibraryMetrics[0].instrumentationLibrary; | ||
resourceMetrics.push({ instrumentationLibrary: lib, instrumentationLibraryMetrics, schemaUrl: lib.schemaUrl }); |
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.
Noticed 1 thing - the instrumentation library schema URL is converted to the resource schema URL. Is it supposed to be like this? See the comment here: https://github.com/open-telemetry/opentelemetry-proto/blob/v0.14.0/opentelemetry/proto/metrics/v1/metrics.proto#L55-L58
Just need clarification, noticed while prepping a followup to this PR to use the new SDK metric types and can rectify it there.
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.
good catch
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 like the current types don't provide a schema url for the resource. I'll remove it and leave a TODO in the code.
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.
actually it doesn't work like you're thinking. The resource schema url would live next to the resourcemetrics array, not within it. In any case, the types in this particular function are not otlp types so I renamed them to make it more obvious what they represent. You can look at the tests to see that the output is correct.
The CI failures for sdk-node resource detectors should have been fixed by #2844. |
Browser test failure seems unrelated |
related: #2665
This is an alternative to #2691 which includes only the types and hand-rolled transformation functions to convert traces and metrics into otlp json. Skipping protobufjs drastically reduces the complexity and size of the final binary, which will be important in the browser context.
It also includes a descriptor.json file in the root of the package which can be loaded by protobufjs and used to serialize messages into protobuf.
todo: