Per-Instrumentation Configuration via Environment Variables

[emmanuel-adu]

Is your feature request related to a problem? Please describe.

Yes. Currently, users cannot configure instrumentation-specific options (like GraphQLInstrumentation.mergeItems, PinoInstrumentation.disableLogSending, etc.) without using global.configureInstrumentations(), which requires code changes and defeats the "zero-code" promise.

The problem: When you define global.configureInstrumentations(), it completely replaces the default instrumentation system. You must manually import and configure ALL instrumentations you want, and OTEL_NODE_ENABLED_INSTRUMENTATIONS is ignored.

Example: To configure GraphQL with mergeItems: true while keeping http, grpc, pg, pino enabled, you must manually import and configure all 5 instrumentations in code, even though you only want to customize GraphQL.

// Must be at the top of handler file, before any imports
global.configureInstrumentations = async () => {
  // Must import ALL instrumentations manually
  const { GraphQLInstrumentation } = await import(
    "@opentelemetry/instrumentation-graphql"
  );
  const { HttpInstrumentation } = await import(
    "@opentelemetry/instrumentation-http"
  );
  const { GrpcInstrumentation } = await import(
    "@opentelemetry/instrumentation-grpc"
  );
  const { PgInstrumentation } = await import(
    "@opentelemetry/instrumentation-pg"
  );
  const { PinoInstrumentation } = await import(
    "@opentelemetry/instrumentation-pino"
  );

  return [
    new GraphQLInstrumentation({ mergeItems: true }), // Only GraphQL needs custom config
    new HttpInstrumentation(), // But must still include all others
    new GrpcInstrumentation(),
    new PgInstrumentation(),
    new PinoInstrumentation(),
  ];
};

Describe the solution you'd like

Add support for OTEL_INSTRUMENTATION_CONFIGS environment variable that accepts a JSON object mapping instrumentation names to their configurations. This works alongside OTEL_NODE_ENABLED_INSTRUMENTATIONS:

# Environment variables only - no code changes needed!
OTEL_NODE_ENABLED_INSTRUMENTATIONS="graphql,http,grpc,pg,pino"
OTEL_INSTRUMENTATION_CONFIGS={"graphql":{"mergeItems":true},"pino":{"disableLogSending":true}}

This would:

• Use OTEL_NODE_ENABLED_INSTRUMENTATIONS to determine which instrumentations to load (existing behavior)
• Apply configuration from OTEL_INSTRUMENTATION_CONFIGS to respective instrumentations
• Use defaults for instrumentations not specified in the config

Implementation: Add loadInstrumentationConfigs() function to parse the env var, and update defaultConfigureInstrumentations() in nodejs/packages/layer/src/wrapper.ts to merge user configs with defaults when creating instrumentations.

Describe alternatives you've considered

1. Per-instrumentation environment variables (e.g., OTEL_PINO_CONFIG) - Rejected: Would pollute env vars and doesn't scale with 30+ instrumentations
2. Keep current global.configureInstrumentations() approach - Rejected: Requires code changes, breaks zero-code promise
3. Configuration file - Rejected: Environment variables are more standard for Lambda and work better with AWS Systems Manager Parameter Store/Secrets Manager

Additional context

Benefits:

• True zero-code configuration via environment variables
• Works seamlessly with existing OTEL_NODE_ENABLED_INSTRUMENTATIONS
• Fully backwards compatible
• No code changes required in Lambda functions

Affected instrumentations: All 30+ instrumentations in the layer

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[herin049]

What's wrong with configuration file based approach? Packaging configuration files with a Lambda function is very straightforward and if you're concerned about packaging/size constraints you can always host the files externally in S3. In my opinion, having an environment variable that accepts JSON is very ugly and error prone. Plus, with the configuration file approach, we can add support for SSM for example with the following YAML

db_user: "${aws_ssm:/my/application/username}"

[emmanuel-adu]

Thanks for the feedback @herin049. I agree JSON-in-env can be ugly/error-prone. I'm not against a config-file approach, that could be the cleaner long-term solution, especially if we want SSM-style interpolation later.

My main goal is enabling per-instrumentation options w/o replacing the default set. Today gloabl.configureInstrumentations() forces you to manually import/configure everything and ignores OTEL_NODE_ENABLED_INSTRUMENTATIONS which breaks the zero-code promise.

I'd be happy with file-first as long as it preserves the default loading behavior while allowing targeted config.