MeterProvider should provide a method to update the resource

[jsumners-nr]

opentelemetry-js/packages/sdk-metrics/src/MeterProvider.ts

Lines 48 to 51 in 96a2ecf

	constructor(options?: MeterProviderOptions) {
	this._sharedState = new MeterProviderSharedState(
	options?.resource ?? defaultResource()
	);

The MeterProvider implementation accepts a Resource instance, but it does not provide a way to update that resource after construction. I definitely have use cases for updating the resource post-construction, e.g. to update the attributes attached to it.

[pichlermarc]

Hi @jsumners-nr, thanks for reaching out - this request looks like it's better suited for https://github.com/open-telemetry/opentelemetry-specification (this issue here is possibly a partial duplicate of open-telemetry/opentelemetry-specification#1298). AFAIK no SDK provides this functionality today as resources are intended to be immutable by the specification [1], [2]

There will be Resources that will be mutable, and the the specification will likely be written by the Entities Working Group as it is listed as a blocker for their work (see Phase 1B). The changes that we made with the bump to @opentelemetry/resources@2.0.0 were primarily done to prepare our code-base for that feature. Once the specification for this is sufficiently defined we will also implement it in OTel JS.

[jsumners-nr]

I am not suggesting updating the existing attached Resource instance. I am suggesting adding a method to MeterProvider that will replace the underlying Resource instance with a new one.

[pichlermarc]

I understand - while what you're asking for is not explicitly prohibited by the specification, it is functionally equivalent to mutable resource attributes (unless you also want to mutate Schema URL). Therefore my interpretation of the specification is that exchanging the full resource after creating a MeterProvider is also not intended.

From looking at other language SIGs SDK implementations, it seems be the most common interpretation of the spec.

In any case, this is something that we would either require specification (mutating resource attributes) for or a clarification in the spec (specifically allowing switching the resource on runtime).

Note that adding custom (non-resource) attributes to every metric is possible. I don't know if that would be an acceptable workaround for your use-case, but this is how to do it:

const meterProvider = new MeterProvider({
  resource: myResource,
  views: [
    {
      attributesProcessors: [
        // custom processor to add/override an attribute on every metric,
        // gets called everytime a something is recorded
        {
          process(incoming): Attributes {
            incoming['my.custom.attribute'] = 'my-attribute';
            return incoming;
          },
        },
      ],
      // apply to every instrument
      instrumentName: '*',
    },
  ],
  readers: [reader],
});

[jsumners-nr]

or a clarification in the spec (specifically allowing switching the resource on runtime).

Why would that be necessary?

Note that adding custom (non-resource) attributes to every metric is possible. I don't know if that would be an acceptable workaround for your use-case, but this is how to do it:

This might work. I'll have to do some testing. But it would be far easier if we could simply replace the resource.

[pichlermarc]

or a clarification in the spec (specifically allowing switching the resource on runtime).

Why would that be necessary?

As a maintainer I have the authority to block features that do not align with the specification. My interpretation is this:

Replacing the Resource during the lifetime of a MeterProvider is functionally equivalent to mutable resources and therefore not specification compliant.

A spec clarification is the most sustainable because if my interpretation happens to be incorrect, it prevents the same misunderstanding recurring elsewhere in the future.

There's an intermediate step that we can do in-between and ask all other JS SIG Maintainers for their opinions here. (cc @open-telemetry/javascript-maintainers, please comment if you agree/disagree with my interpretation above)

[legendecas]

It is required by the specification that the resource attributes are immutable. So updating a resource is a non-starter.

However, it is allowed to deferring the resource attributes creation via async resource attributes:

class DeferredDetector implements ResourceDetector {
  _deferredMyAttrResolver = Promise.withResolvers();

  detect(_config?: ResourceDetectionConfig): DetectedResource {
    const attributes: DetectedResourceAttributes = {
      my_attr: this._deferredMyAttrResolver.promise,
    };

    return { attributes };
  }

  // Invoke this method once the attribute is known at a later time.
  resolveMyAttr(value: AttributeValue) {
    this._deferredMyAttrResolver.resolve(value);
  }
}

// Or

const deferredMyAttrResolver = Promise.withResolvers();
const resource = resourceFromAttributes({
  my_attr: deferredMyAttrResolver.promise,
});

// do something async
deferredMyAttrResolver.resolve(value);

Still, this only defers the attribute detection. It does not allow mutate the resource after its creation.

[jsumners-nr]

We do not want to mutate the resource. We want to:

meterProviderInstance.resource = resourceFromAttributes({ foo: 'bar' })

[legendecas]

It is explicitly disallowed by the spec that an association of a resource with a TracerProvider or a MeterProvider can not be changed later.

The resource is the identity of the telemetry provider. This may change the assumption in telemetry consumers and a change must be submitted to the specification first like @pichlermarc mentioned at #5876 (comment).

[jsumners-nr]

Without being able to update the resource it is possible the resource no longer identifies the data correctly.

[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.