document load plugin assumes w3c trace context propagator

[mwear]

Please answer these questions before submitting a bug report.

What version of OpenTelemetry are you using?

otel v0.12.x, document-load v0.11.0

What did you do?

Configured b3 context propagation

What did you expect to see?

A connected trace

Additional context

The document-load plugin assumes that there is a meta tag named traceparent in a response and sythesizes a carrier using it. See:

opentelemetry-js-contrib/plugins/web/opentelemetry-plugin-document-load/src/documentLoad.ts

Lines 90 to 96 in 6449f22

	const metaElement = [...document.getElementsByTagName('meta')].find(
	e => e.getAttribute('name') === TRACE_PARENT_HEADER
	);
	const entries = this._getEntries();
	const traceparent = (metaElement && metaElement.content) || '';
	context.with(propagation.extract({ traceparent }), () => {

This does not work if you are using b3 context propagation, as it does not understand carrier built with a hardcoded traceparent. It needs a carrier built with the fields expected by a B3 propagator. I think we could make this plugin propagator agnostic by doing the following:

• instead of writing a traceparent as a meta tag in an http response, write a metatag for each field in Propagator#fields
• the document load plugin can synthesize a carrier by iterating over Propagator#fields and looking for corresponding meta tags. use that carrier when extracting here

[obecny]

After some investigation and even a way of trying to implement I'm back in position that we should not do it. Because this is not needed and will add just more complexity and non standard things for propagating and reading context. Will show how to do it.
Besides that the fields method is method of propagator which you don't have access to - method _getGlobalPropagator is private.

1. B3 propagator is meant to be used when propagate using headers. Not using meta tags. For that we have traceparent HttpTraceContext propagator.

2. Then propagation of B3 headers is strictly connected with using XMLHTTP Plugin / Instrumentation, or fetch plugin. This plugin by default will only add headers for the same origin. If the headers should be added for any other domain there is a configuration option which needs to be set. It is called propagateTraceHeaderCorsUrls. It accepts string or regexp or array of string and regexp.

Having that all im mind it is enough to be able to set the propagation correctly between server->client->server

For example

import { ConsoleSpanExporter, SimpleSpanProcessor } from '@opentelemetry/tracing';
import { WebTracerProvider } from '@opentelemetry/web';
import { DocumentLoad } from '@opentelemetry/plugin-document-load';
import { XMLHttpRequestInstrumentation } from '@opentelemetry/instrumentation-xml-http-request';
// ver 0.12 import { XMLHttpRequestPlugin } from '@opentelemetry/plugin-xml-http-request';
import { ZoneContextManager } from '@opentelemetry/context-zone';
import { CollectorTraceExporter } from '@opentelemetry/exporter-collector';
import { B3Propagator } from '@opentelemetry/propagator-b3';
// ver 0.12 import { B3Propagator } from '@opentelemetry/core';
import { CompositePropagator, HttpTraceContext } from '@opentelemetry/core';

const provider = new WebTracerProvider({
  plugins: [
    new DocumentLoad(),
    new XMLHttpRequestInstrumentation({
      propagateTraceHeaderCorsUrls: /.+/,
    }),
    // or when using v.012
//    new XMLHttpRequestPlugin({
//      propagateTraceHeaderCorsUrls: /.+/,
//    }),
  ],
});
provider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));
provider.addSpanProcessor(new SimpleSpanProcessor(new CollectorTraceExporter()));

provider.register({
  contextManager: new ZoneContextManager(),
  propagator: new CompositePropagator({
    propagators: [
      new B3Propagator(),
      new HttpTraceContext(),
    ],
  }),
});

This is setup for document load plugin.

It missing just one final piece which will allow to pickup context from server and set it to be propagated. It requires to add meta tag information to head section of page for example

<meta name="traceparent" content="00-ab42124a3c573678d4d8b21ba52df3bf-d21f7bc17caa5aba-01">

Having B3Propagator and HttpTraceContext plus XMLHttpRequestInstrumentation (XMLHttpRequestPlugin) will propagate traceparent correctly. It will add this information to

1. All spans created during page load will be bound to traceparent context
2. All XMLHTTPRequests will have b3 headers with correct context extracted from traceparent.

This is enough setup all should be propagated correctly.

@mwear @dyladan ^^

[obecny]

https://ibb.co/GnBDKRS

[obecny]

And the most important thing when any plugin is using mixed version of api (v.012 with 0.13 for example), the default propagation is Noop and nothing works

[dyladan]

Besides that the fields method is private method of propagator which you don't have access to - method _getGlobalPropagator is private

Hmm this is a bug. You should be able to api.propagation.fields() according to the spec.

[obecny]

@dyladan if you have propagator then you can access fields, but you cannot access it via api.propagation.fields() or you cannot get default propagation (_getGlobalPropagator is private)

[dyladan]

You should be able to. The use-case is that an instrumentation which reuses a carrier should be able to know which fields to clear. In the instrumentation you won't know which propagator is used.

[obecny]

fine, but I'm talking of what it is now possible or not, not how it should be :)

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[dyladan]

not stale afaik