-
Notifications
You must be signed in to change notification settings - Fork 821
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: browser support for exporter-trace-otlp-proto #3208
feat: browser support for exporter-trace-otlp-proto #3208
Conversation
b4effd1
to
3dd4e17
Compare
collector.timeoutMillis, | ||
onSuccess, | ||
onError | ||
); |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to call this folder fetch-proto
to keep it simple
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing it out. I will make the changes.
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.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dyladan @legendecas can you please comment on the above observation?
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.
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.
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.
Left suggestion for getDefaultUrl()
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.
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 <[email protected]>
that will now be used for the browser case as well.
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.
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: