Skip to content
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

Merged
merged 51 commits into from
Jan 20, 2023

Conversation

pkanal
Copy link
Contributor

@pkanal pkanal commented Aug 26, 2022

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

  • Compression options
  • Add karma config for tests
  • Add unit tests
  • Add example of using the proto exporter in the browser
  • Finish up tests listed below

Short description of the changes

  • Added browser exporter for the proto exporter package
  • Added browser exporter for trace proto exporter package
  • Added example using the trace proto exporter package

Type of change

Please delete options that are not relevant.

  • New feature (non-breaking change which adds functionality)
  • This change requires a documentation update

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

  • Send traces in the browser using the proto exporter
  • Node proto exporter still works as expected
  • Env variables are supported
  • Existing config is supported

Checklist:

  • Followed the style guidelines of this project
  • Unit tests have been added
  • Documentation has been updated

@pkanal pkanal changed the title Proto exporter browser [WIP] Browser support for exporter-trace-otlp-proto Aug 26, 2022
@pkanal pkanal marked this pull request as ready for review October 12, 2022 14:53
@pkanal pkanal requested a review from a team October 12, 2022 14:53
@pkanal pkanal changed the title [WIP] Browser support for exporter-trace-otlp-proto feat: browser support for exporter-trace-otlp-proto Oct 12, 2022
collector.timeoutMillis,
onSuccess,
onError
);
Copy link
Contributor

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");
Copy link
Contributor

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?

Copy link
Member

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';
Copy link
Contributor

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?

Copy link
Member

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>
Copy link
Contributor

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

Copy link
Member

@pichlermarc pichlermarc left a 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/package.json Outdated Show resolved Hide resolved
examples/opentelemetry-web/package.json 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");
Copy link
Member

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 🙂

@codecov
Copy link

codecov bot commented Nov 8, 2022

Codecov Report

Merging #3208 (426f321) into main (5127371) will decrease coverage by 0.02%.
The diff coverage is n/a.

❗ Current head 426f321 differs from pull request most recent head 9429864. Consider uploading reports for the commit 9429864 to get more accurate results

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     
Impacted Files Coverage Δ
...-otlp-proto/src/platform/node/OTLPTraceExporter.ts 100.00% <ø> (ø)
packages/opentelemetry-resources/src/Resource.ts 100.00% <ø> (ø)
...-trace-base/src/platform/node/RandomIdGenerator.ts 87.50% <0.00%> (-6.25%) ⬇️

@scheler
Copy link
Contributor

scheler commented Nov 12, 2022

@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 api/test/tree-shaking/tree-shaking.test.ts (even though this PR has made no changes to the api), but it's not clear if the unit tests in github CI are failing for the same reason. Thanks for looking into this.

@legendecas
Copy link
Member

@scheler I'll take a look at the CI problem.

}

getDefaultUrl(config: OTLPExporterConfigBase): string {
return typeof config.url === 'string'
Copy link
Contributor

@MSNev MSNev Dec 14, 2022

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

Copy link
Contributor

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.

Copy link
Contributor

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<
Copy link
Member

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?/

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Member

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.

tsconfig.base.esm.json Outdated Show resolved Hide resolved
Copy link
Contributor

@MSNev MSNev left a 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()

Copy link
Member

@pichlermarc pichlermarc left a 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 🙂

Copy link
Member

@pichlermarc pichlermarc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the great work on this @pkanal and @scheler 💯
This is no doubt going to help out a lot of people. 🙂

@legendecas
Copy link
Member

Thank you for working on this!

@scheler
Copy link
Contributor

scheler commented Jan 19, 2023

@open-telemetry/javascript-maintainers can you review and merge this PR? It has a few approvals already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Protobuf trace exporter for browser
6 participants