What is the best way to handle No-Op

[simonfl3tcher]

👋🏻 I am looking for some help on how to control rollout of OTEL thus to minimize the risk of accidentally bursting our 💰

Currently our setup is pretty vanilla, we instantiate the OTEL library before anything else runs in order to get the tracing / metrics from the very first start of the stack. The injection of this requirement is handled by our IAC. Namely we have our k8s configuration making the decisions on whether to require the otel setup or not on boot. This gives us a nice way to incrementally rollout the OTEL library to individual deployments, however the ability to use this as a kill switch is limited due to deployment time. As such I am looking to have a kill switch within the otel code itself via a feature flag setting.

The code where we call the SDK looks like this:

export class Client {
    private sdk: NodeSDK | undefined = undefined;

    constructor() {
        this.sdk = new NodeSDK({
            traceExporter: new OTLPTraceExporter(),
            metricReader: new PeriodicExportingMetricReader({
                exporter: new OTLPMetricExporter(),
                exportIntervalMillis: 60000,
            }),
        });
    }

    public start(): void {
        return this.sdk?.start();
    }

    public async shutdown(): Promise<void> {
        return this.sdk?.shutdown();
    }
}

export const meter = (): Meter => opentelemetry.metrics.getMeter("myapp");

export const tracer = (): Tracer => {
    return opentelemetry.trace.getTracer("myapp", process.env.HEAD_SHA);
};

We could of course feature flag the call sites for meter and tracer but that feels suboptimal. I was wondering if there was a way to encapsulate a kill switch from this module somehow? Namely, say something like "if the feature flag is enabled publish to the OTLP endpoint, if not, do nothing".

No-op

I understand that there is a no-op spec for metrics which seems to address this requirement. It looks like we have support for this via NoopMeterProvider and NoopTracerProvider. So my question is two fold...

Would setting the setGlobalTracerProvider with these classes give me what I want? i.e. to keep the interfaces the same but just simply drop the calls on the floor?

import { NoopMeterProvider } from "@opentelemetry/api/build/src/metrics/NoopMeterProvider";
import { NoopTracerProvider } from "@opentelemetry/api/build/src/trace/NoopTracerProvider";

export class Client {
    private sdk: NodeSDK | undefined = undefined;

    constructor() {
        if (getFeatureSetting("mycondition") === true) {
            opentelemetry.metrics.setGlobalMeterProvider(new NoopMeterProvider());
            opentelemetry.trace.setGlobalTracerProvider(new NoopTracerProvider());
        }

        this.sdk = new NodeSDK({
            traceExporter:  new OTLPTraceExporter(),
            metricReader: new PeriodicExportingMetricReader({
                exporter: new OTLPMetricExporter(),
                exportIntervalMillis: 60000,
            }),
        });
    }

    public start(): void {
        return this.sdk?.start();
    }

    public async shutdown(): Promise<void> {
        return this.sdk?.shutdown();
    }
}

export const meter = (): Meter => opentelemetry.metrics.getMeter("myapp");

export const tracer = (): Tracer => {
    return opentelemetry.trace.getTracer("myapp", process.env.HEAD_SHA);
};

And secondly is importing the providers from src the right way to do this. I don't think that they are exported from the top level of the package?

import { NoopMeterProvider } from "@opentelemetry/api/build/src/metrics/NoopMeterProvider";
import { NoopTracerProvider } from "@opentelemetry/api/build/src/trace/NoopTracerProvider";

Thanks in advance for your help ❤️

[Flarna]

If you never call setGlobalTracerProvider or setGlobalMeterProvider the Noop implementations are active.

e.g. trace.getTracer() should return a ProxyTracer which redirects to a NoopTracer which more or less does nothing.

Note that the NoopContextManager will always return the empty ROOT_CONTEXT as a result trace.getActiveSpan() will always return undefined.

So whenever you operate on trace.getActiveSpan() you should be prepared for getting undefined, even here:

tracer.startActiveSpan("span", (span) => {
  span.setAttribute("key", "value");                     // ok, this is a noop
  const activeSpan = trace.getActiveSpan();       // returns span with real context manager but undefined in case of NooP
  activeSpan.setAttribute("key", "value");           // not ok
});

[simonfl3tcher]

If you never call setGlobalTracerProvider or setGlobalMeterProvider the Noop implementations are active.

This is interesting, because I wasn't setting this and I was able to generate metrics which are sent to the OTLP endpoint? This was following this documentation:

https://opentelemetry.io/docs/instrumentation/js/manual/

I am wondering if the SDK auto initializes this somewhere?

[simonfl3tcher]

OK yeah it looks like it does auto set this for us here:

https://github.com/open-telemetry/opentelemetry-js/blob/ae0a3c522d0b802de264e4d8b9566d3677a36ee6/experimental/packages/opentelemetry-sdk-node/src/sdk.ts#L161C17-L165

opentelemetry-js/experimental/packages/opentelemetry-sdk-node/src/sdk.ts

Line 364 in ae0a3c5

metrics.setGlobalMeterProvider(meterProvider);

[simonfl3tcher]

If I am reading this block correctly:

opentelemetry-js/experimental/packages/opentelemetry-sdk-node/src/sdk.ts

Lines 161 to 172 in ae0a3c5

	if (configuration.metricReader || configuration.views) {
	const meterProviderConfig: MeterProviderConfig = {};
	if (configuration.metricReader) {
	meterProviderConfig.reader = configuration.metricReader;
	}
	if (configuration.views) {
	meterProviderConfig.views = configuration.views;
	}
	this.configureMeterProvider(meterProviderConfig);
	}

It means that if we do not provide a metricReader it will default to noop for the meter, so I would need to change the block so something like:

        this.sdk = new NodeSDK({
            traceExporter:  new OTLPTraceExporter(),
            metricReader: getFeatureSetting("mycondition") === true ? new PeriodicExportingMetricReader({
                exporter: new OTLPMetricExporter(),
                exportIntervalMillis: 60000,
            }) : undefined,
        });

It also looks like it's the same for the traceExporter looking at this block of code:

opentelemetry-js/experimental/packages/opentelemetry-sdk-node/src/sdk.ts

Lines 129 to 152 in ae0a3c5

	if (configuration.spanProcessor || configuration.traceExporter) {
	const tracerProviderConfig: NodeTracerConfig = {};
	if (configuration.sampler) {
	tracerProviderConfig.sampler = configuration.sampler;
	}
	if (configuration.spanLimits) {
	tracerProviderConfig.spanLimits = configuration.spanLimits;
	}
	if (configuration.idGenerator) {
	tracerProviderConfig.idGenerator = configuration.idGenerator;
	}
	const spanProcessor =
	configuration.spanProcessor ??
	new BatchSpanProcessor(configuration.traceExporter!);
	this.configureTracerProvider(
	tracerProviderConfig,
	spanProcessor,
	configuration.contextManager,
	configuration.textMapPropagator
	);
	}

So I think the overall fix is to conditionally set these depending on the feature flag setting, right? So something like:

        this.sdk = new NodeSDK({
            traceExporter:  getFeatureSetting("mycondition") === true ? new OTLPTraceExporter() : undefined,
            metricReader: getFeatureSetting("mycondition") === true ? new PeriodicExportingMetricReader({
                exporter: new OTLPMetricExporter(),
                exportIntervalMillis: 60000,
            }) : undefined,
        });

By doing this it will use the noop implementations by default, is that correct?

[Flarna]

well, if you start the SDK it's expected that the SDK is started and it does it's job to create traces, metrics,...
Just don't start the SDK if you don't want this.

The API is built to work without SDK. This allows to write instrumentations using API only as dependency. If there is an SDK they create real spans/metrics if not it's a noop (with hopefully minimal overhead).

[simonfl3tcher]

The API is built to work without SDK. This allows to write instrumentations using API only as dependency. If there is an SDK they create real spans/metrics if not it's a noop (with hopefully minimal overhead).

Ah OK so just do not instantiate the SDK and we will essentially be in a "noop" position? So something like this:

export class Client {
    private sdk: NodeSDK | undefined = undefined;

    constructor() {
       if(getFeatureSetting("myfeature") === true) {
          this.sdk = new NodeSDK({
              traceExporter: new OTLPTraceExporter(),
              metricReader: new PeriodicExportingMetricReader({
                  exporter: new OTLPMetricExporter(),
                  exportIntervalMillis: 60000,
              }),
          });
        }
    }

    public start(): void {
        return this.sdk?.start();
    }

    public async shutdown(): Promise<void> {
        return this.sdk?.shutdown();
    }
}

And then just to validate what I am reading, the call below will not raise an error with the logic like ☝🏻 because then it just uses the API and because we haven't instantiated the SDK, it will run with the noop implementations, correct?

opentelemetry.metrics.getMeter("myapp")

[Flarna]

Correct. If it is different it's a bug.
I have never tried this by myself with metrics but a lot with traces.

[simonfl3tcher]

I have never tried this by myself with metrics but a lot with traces.

This works! Thank you so much @Flarna I really appreciate your time.

[polRk]

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './build/src/metrics/NoopMeterProvider' is not defined by "exports"