Skip to content

feat(opentelemetry): add resource configuration support #1151

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Dzheky
Copy link

@Dzheky Dzheky commented May 23, 2025

Description

Adds support for custom resource attributes configuration in the OpenTelemetry plugin, enabling users to specify additional resource metadata like deployment.environment, service.instance.id, and other custom attributes.

Example

{
  //...
  openTelemetry: {
    exporters: [createOtlpHttpExporter({ url: 'http://localhost:4318' })],
    serviceName: 'my-gateway',
    resource: {
      'deployment.environment': 'production',
      'service.instance.id': process.env.HOSTNAME,
      'service.namespace': 'platform',
      'service.name': 'custom-service-name', // Overrides serviceName
    },
  }
  //...
}

Why

Previously, users could only configure service.name via the serviceName option. This limitation made it difficult to add essential resource attributes like deployment environment, instance IDs, or custom metadata that are needed for proper observability and trace correlation in production environments.

Related Issues
#1149

@enisdenjo
Copy link
Member

@EmrysMyrddin care to take a look? Is this something we'll have in v2?

@EmrysMyrddin
Copy link
Collaborator

Yes, this is something that will be possible in v2. I'm currently working on configuration changes!

Anyway, it is already possible, you can disable automatic sdk initialization and do your own OTEL setup. I would recommend this over the automatic configuration for a production configuration, it will give you the full control of OTEL behavior.

@Dzheky
Copy link
Author

Dzheky commented May 27, 2025

@EmrysMyrddin This is how we currently did this, it would be still nice to have this in automatic initialisation. So should this PR be closed and it will be implemented in v2?

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

Successfully merging this pull request may close these issues.

3 participants