Is there a way to disable the _metrics_ from @opentelemetry/instrumentation-http?

[pvogel1967]

The metrics delivered by this instrumentation are redundant with the span data they generate and are generating unnecessary metric volume for us. Is there a way to use the instrumentation so it does what it documents it does (collect traces for incoming and outgoing http requests) and does not do what it is doing but which is not documented, namely generating metrics http.server.duration and http.client.duration?

[Apokalypt]

I would love a solution for this also ... Is there any news or solution I missed for that ?

[pichlermarc]

There's a way yes. You can drop all metrics generated by the instrumentation by adding this View when instantiating the MeterProvider (NodeSDK has the same option, in case you're using that):

new MeterProvider({
  views: [
    new View({
        meterName: '@opentelemetry/instrumentation-http',
        aggregation: Aggregation.Drop()
    })
  ],
  // any of your additional config goes here
};

See also: https://opentelemetry.io/docs/languages/js/instrumentation/#configure-metric-views

[Apokalypt]

Thanks for this precision, but another question related to this : is there a way to disable ALL metrics ? Not only from @opentelemetry/instrumentation-http but also all other libraries ?

[anushkadoyan]

Hi @pichlermarc, I tried this through the NodeSDK config and am still seeing the http metrics:

  const sdkOptions: Partial<NodeSDKConfiguration> = {
    serviceName: config.target,
    views: [
      // disable metrics from instrumentation-http
      new View({
        meterName: '@opentelemetry/instrumentation-http',
        aggregation: Aggregation.Drop(),
      }),
    ],
  };

Is this correct?

[pichlermarc]

@Apokalypt OpenTelemetry is designed in a way that you don't need to register an OpenTelemetry Metrics SDK if you don't want the metrics. By simply not registering a global MeterProvider all metrics will be dropped.

@anushkadoyan I was able to verify that this works on the latest version, I used the below code - this drops all metrics from @opentelemetry/instrumentation-http:

import {NodeSDK, NodeSDKConfiguration} from "@opentelemetry/sdk-node";
import {Aggregation, ConsoleMetricExporter, PeriodicExportingMetricReader, View} from "@opentelemetry/sdk-metrics";
import {HttpInstrumentation} from "@opentelemetry/instrumentation-http";
import {diag} from "@opentelemetry/api";

const sdkOptions: Partial<NodeSDKConfiguration> = {
    instrumentations: [new HttpInstrumentation()],
    views: [
        // disable metrics from instrumentation-http
        new View({
            meterName: '@opentelemetry/instrumentation-http',
            aggregation: Aggregation.Drop(),
        }),
    ],
    metricReader: new PeriodicExportingMetricReader({exporter: new ConsoleMetricExporter()})
};

const sdk = new NodeSDK(sdkOptions);
sdk.start();


async function shutdown(): Promise<void> {
    try {
        await sdk.shutdown();
        diag.debug('OpenTelemetry SDK terminated');
    } catch (error) {
        diag.error('Error terminating OpenTelemetry SDK', error);
    }
}

// Gracefully shutdown SDK if a SIGTERM is received
process.on('SIGTERM', shutdown);
// Gracefully shutdown SDK if Node.js is exiting normally
process.once('beforeExit', shutdown);

[anushkadoyan]

@pichlermarc thank you!

[cosminstefanxp]

Do you have any suggestion for how this can be approached when using @azure/monitor-opentelemetry's useAzureMonitor? I unfortunately don't have access to NodeSDK in there.

[daniellockyer]

I wonder if we need a way to disable the metrics generation from the library. From a quick investigation, it's causing a ~10% performance loss just from this alone. It'd be less if the attribute hashing function is improved but still 5% or so