-
Notifications
You must be signed in to change notification settings - Fork 796
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!: Split metric and trace exporters into new experimental packages #2485
Conversation
@obecny I'm not sure if this is meaningful, but I saw you wrote (or at least refactored) these exporters. The Metrics gRPC exporter is failing two of the export unit tests after I moved it to experimental - one with TLS, and another without TLS but with metadata. The strange thing is they were (obviously) passing beforehand as part of the stable package, and the gRPC Trace exporter tests, which are nearly identical, still pass no problem. The closest thing to a reason I've identified for the failure is here in exporter-otlp-grpc. The trace export tests that pass seem to call this Anyway, here's the error output, please let me know if there's anything obvious:
|
Also, the tests are failing because the experimental metric packages depend on the stable packages. However because of the separation between experimental/stable, the experimental packages try to pull in the newly-renamed trace exporter packages and fail to find them. However with the exception of the above failing tests, I have verified the rest of the refactor by publishing the stable exporters to a local registry (verdaccio) and using that for experimental package testing. |
Blocked on #2490, then will rebase and open for 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.
lgtm, i would wait for @obecny review since he wrote all the otlp exporter.
Wouldn't it make sense to rename the current |
@vmarchaud I think that'd make sense, but I'd be hesitant for a few reasons:
Of course would like to hear from the other maintainers as well though |
About 1), i think it make more sense of having different exporters for each signal, since they are generally packaged by distro i don't really see the point of trying to have them in a single package, WDYT ? For 2) You are right about that but i would prefer to make that change now instead of after 1.0 them |
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.
Wouldn't it make sense to rename the current
otlp-exporter
totrace-otlp-exporter
when releasing it as 1.0 though ?
IMO, Whether it makes sense or not depends on if we intend to add metrics functionality into otlp-exporter
or not once metric-specific functionality is stable.
If we do, let's not rename those packages back-and-forth to reflect their current state, but just think of otlp-exporter
as "the general purpose exporter which just happens to only have tracing support right now, but eventually will have more".
That said, I wouldn't rename otlp-exporter
to trace-otlp-exporter
.
@dyladan just to confirm before I make this last change, after this PR is merged there will be 6 new packages in
Does that look right? Also, should I go ahead and rename the directories of the trace exporters to include trace? E.g.
|
Yes to both |
@open-telemetry/javascript-approvers this should be ready for review now, PTAL! |
This PR is absolutely enormous which makes it difficult to review. Can you confirm some things for me?
|
Yes. The only source code files I manipulated in non-automated ways were the |
@dyladan @vmarchaud hopefully the end of these pesky conflicts 😄 |
@obecny I would prefer to have your approval since you initialy wrote all otlp exporter |
I raised couple times that we could do few things differently and have separate class for converting data - something that @blumamir was trying to achieve some time ago. I don't want to block it but also I had quite different view of how it could be done. My confidence level for so many changes is really low and it is impossible for me to be sure that nothing is broken. I wanted to leave things in experimental as they are and then create new things (including refactoring) out of this so we will have longer time for people to change to new packages and still have a backup plan if anything doesn't work as expected. We would be having "doubled" packages for some time but at least we will not break anything without giving people a chance to compare both packages - only downgrade will be possible :/. I simply don't feel confident enough with so many changes and being already "stable". |
Nothing here is stable. These packages are being created in the experimental folder. The reason for the extensive test suites is to be able to do large refactorings and have some level of confidence that the package still works. These will still live in experimental for a period of time until we are sure nothing is broken. There is also nothing preventing it from being refactored with a new implementation. |
@obecny I completely understand the hesitance for such a large change, the PR became bigger than I was hoping it would have to be. That's why I was very careful to make all code changes in automated ways (e.g. find and replace) except to the test helpers I mentioned earlier. We could test these changes by updating the I'm not sure how much value there would have been in still publishing the old joint exporter packages, since there presumably wouldn't be any changes made to it, so it would be the same as just using the current published version. |
Hmm I think that should be checked before this PR is merged. The update of the examples can be separate PR, but I wish you make sure the new packages works fine with few examples before it will be merged (using lerna to bootstrap it). WDYT, can you run those tests ? |
@obecny I validated that the OTLP exporter sample app works as expected for exporting both traces and metrics after these changes. You can see the changes in my other PR for the sample app: https://github.com/open-telemetry/opentelemetry-js/pull/2577/files#diff-ad989b2d87fe5747576d5a98f3819e195a3053857fd4b0de12c9f5417e0dadd4 |
@obecny does that satisfy your concern? If so, I would merge this. |
thx, appreciate it ! |
Which problem is this PR solving?
Background
This PR removes all metric logic from the main OTLP exporter packages and moves them into new packages. I am leaving this PR in draft until the updated core exporters are released.
Short description of the changes
@opentelemetry/exporter-metrics-otlp-http
@opentelemetry/exporter-metrics-otlp-grpc
@opentelemetry/exporter-metrics-otlp-proto
experimental
directoryOTLPExporterBrowserBase
class from the browser class - just want to make sure this is ok since I couldn't find any other classes exported from abrowser
platformRemaining blockers
metrics-otlp-grpc
. @obecny I don't think the tests will be reproduced here but maybe you can help me take a look.