feat: browser support for exporter-trace-otlp-proto #3208
feat: browser support for exporter-trace-otlp-proto #3208legendecas merged 51 commits intoopen-telemetry:mainfrom
Conversation
b4effd1 to
3dd4e17
Compare
| collector.timeoutMillis, | ||
| onSuccess, | ||
| onError | ||
| ); |
There was a problem hiding this comment.
Not related to this PR, but I wonder why the headers and timeout are set only in the browser case. In the node case, are the headers passed in env variables OTEL_EXPORTER_OTLP_HEADERS and OTEL_EXPORTER_OTLP_TRACES_HEADERS ignored?
| const { ZoneContextManager } = require( '@opentelemetry/context-zone'); | ||
| const { B3Propagator } = require( '@opentelemetry/propagator-b3'); | ||
| const { registerInstrumentations } = require( '@opentelemetry/instrumentation'); | ||
| const { context, trace } = require("@opentelemetry/api"); |
There was a problem hiding this comment.
Looks like this file has only formatting changes. If so, can you submit them in a separate PR and revert them here?
There was a problem hiding this comment.
We also prefer single quotes over double quotes in the repo, but there is just no eslint rule for *.js files at the moment. For this reason, and for making this PR easier to review, undoning the formatting changes would be greatly appreciated 🙂
| OTLPExporterError, | ||
| OTLPExporterConfigBase | ||
| } from '@opentelemetry/otlp-exporter-base'; | ||
| import { send } from './util'; |
There was a problem hiding this comment.
I wonder what was the reason send function was moved into a separate util, and not OTLPProtoExporterBrowserBase itself. Are there any benefits to doing it?
There was a problem hiding this comment.
See https://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/otlp-grpc-exporter-base/src/OTLPGRPCExporterNodeBase.ts#L78-L79 for the reason for Node.js grpc instrumentation.
I think it is fine to move the util function as a member method for the web, as the send function is accessing many members of the collector and not depends on external modules.
| @@ -0,0 +1,20 @@ | |||
| <!DOCTYPE html> | |||
There was a problem hiding this comment.
You might want to call this folder fetch-proto to keep it simple
pichlermarc
left a comment
There was a problem hiding this comment.
This is great, thank you for working on this 🙂
Just a few smaller comments. 🙂
examples/opentelemetry-web/examples/fetchProtoExporter/index.js
Outdated
Show resolved
Hide resolved
examples/opentelemetry-web/examples/fetchProtoExporter/index.js
Outdated
Show resolved
Hide resolved
| const { ZoneContextManager } = require( '@opentelemetry/context-zone'); | ||
| const { B3Propagator } = require( '@opentelemetry/propagator-b3'); | ||
| const { registerInstrumentations } = require( '@opentelemetry/instrumentation'); | ||
| const { context, trace } = require("@opentelemetry/api"); |
There was a problem hiding this comment.
We also prefer single quotes over double quotes in the repo, but there is just no eslint rule for *.js files at the moment. For this reason, and for making this PR easier to review, undoning the formatting changes would be greatly appreciated 🙂
experimental/packages/otlp-exporter-base/src/platform/browser/OTLPExporterBrowserBase.ts
Outdated
Show resolved
Hide resolved
...ental/packages/otlp-proto-exporter-base/src/platform/browser/OTLPProtoExporterBrowserBase.ts
Outdated
Show resolved
Hide resolved
...ental/packages/otlp-proto-exporter-base/src/platform/browser/OTLPProtoExporterBrowserBase.ts
Outdated
Show resolved
Hide resolved
experimental/packages/otlp-proto-exporter-base/src/platform/browser/util.ts
Outdated
Show resolved
Hide resolved
experimental/packages/otlp-proto-exporter-base/src/platform/browser/util.ts
Outdated
Show resolved
Hide resolved
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3208 +/- ##
==========================================
- Coverage 93.80% 93.79% -0.02%
==========================================
Files 249 249
Lines 7640 7640
Branches 1589 1589
==========================================
- Hits 7167 7166 -1
- Misses 473 474 +1
|
|
@pichlermarc @legendecas @dyladan could one of you help check what the unit tests are failing for? I only see "Error: Process completed with exit code 3." at the end of each tests run, but it's not clear what error the process encountered. In my local setup I see failure in |
|
@scheler I'll take a look at the CI problem. |
| } | ||
|
|
||
| getDefaultUrl(config: OTLPExporterConfigBase): string { | ||
| return typeof config.url === 'string' |
There was a problem hiding this comment.
Suggestion
This is a little more readable, performant (and minifiable) by rewriting as
let endpoint = config.url;
if (!endpoint || endpoint !== 'string') {
let env = getEnv();
let tracesEndpoint = env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT;
if (tracesEndpoint) {
endpoint = appendRootPathToUrlIfNeeded(tracesEndpoint);
} else {
let otlpEndpoint = env.OTEL_EXPORTER_OTLP_ENDPOINT;
if (otlpEndpoint) {
endpoint = appendResourcePathToUrl(otlpEndpoint, DEFAULT_COLLECTOR_RESOURCE_PATH);
}
}
}
return endpoint || DEFAULT_COLLECTOR_URL;As well as less error prone for someone coming looking at this after you
There was a problem hiding this comment.
@MSNev The function getDefaultUrl is written this way in multiple packages. I suggest we take this up in a separate PR since it's unrelated to this PR.
There was a problem hiding this comment.
Can we raise an issue for this then, otherwise it will not get done. This can include the suggestion I have above as the implementation.
| /** | ||
| * Collector Exporter abstract base class | ||
| */ | ||
| export abstract class OTLPProtoExporterBrowserBase< |
There was a problem hiding this comment.
Usually the node and browser exports would have the same name and be chosen at compile time. Is there a reason you've chosen to give it a separate name here?/
There was a problem hiding this comment.
Yeah, we have a section about this rule: https://github.com/open-telemetry/opentelemetry-js/blob/main/CONTRIBUTING.md#platform-conditional-exports.
If it is needed to be exported under different names, it can be placed outside platform/ to avoid unexpected missing exports.
There was a problem hiding this comment.
Thanks for pointing it out. I will make the changes.
There was a problem hiding this comment.
@dyladan @legendecas this doesn't seem to be straightforward. The classes are named differently in platform/ in the package otlp-exporter-base and they follow different interface - that is, one has _headers private member and another has headers public member. I am running into errors using the same name in the platform/ of package otlp-proto-exporter-base. The errors manifest in the package exporter-trace-otlp-proto. It looks like the rule of using the same name for classes in platform/ is not followed already, so I suggest we take this up in a separate PR as it requires changes in multiple packages and requires more care. Let me know what you think.
There was a problem hiding this comment.
@dyladan @legendecas can you please comment on the above observation?
There was a problem hiding this comment.
Sorry for the delayed response. I thought I've hit the comment button.
Yeah, it is true that the rule has already been violated in the package otlp-exporter-base. I think it is fine to defer the renaming since it would not be an easy work without the refactoring in the otlp-exporter-base first.
MSNev
left a comment
There was a problem hiding this comment.
Left suggestion for getDefaultUrl()
pichlermarc
left a comment
There was a problem hiding this comment.
Thank you for moving this along 🙂
It looks like the opentelemetry-web is missing the proto exporter dependency.
I was also wondering about some packaging details - see comments below 🙂
experimental/packages/exporter-trace-otlp-proto/test/browser/CollectorTraceExporter.test.ts
Outdated
Show resolved
Hide resolved
…ollectorTraceExporter.test.ts Co-authored-by: Marc Pichler <marcpi@edu.aau.at>
that will now be used for the browser case as well.
|
Thank you for working on this! |
|
@open-telemetry/javascript-maintainers can you review and merge this PR? It has a few approvals already. |
Which problem is this PR solving?
Provide the option of exporting traces using protobuf from the browser. Previously this package only supported Node, since this package now uses protobuf-js it is possible to send protobuf from the browser.
Fixes #3118
TODOs
Short description of the changes
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist: