Make service.instance.id and other telemetry attributes available to extensions

[tigrannajaryan]

OpAMP extension will need to know the generated service.instance.id and other telemetry attributes to use it in the communication with the OpAMP Server.

This can be implemented by making it available on the component.Host interface or by adding a field to xCreateSettings.

For reference the OpAMP spec requires that in OpAMP protocol the following is set:

For standalone running Agents (such as OpenTelemetry Collector) the following attributes SHOULD be specified:
- service.name should be set to the same value that the Agent uses in its own telemetry.
- service.namespace if it is used in the environment where the Agent runs.
- service.version should be set to version number of the Agent build.
- service.instance.id should be set. It may be be set equal to the Agent's instance uid (equal to ServerToAgent.instance_uid field) or any other value that uniquely identifies the Agent in combination with other attributes.

[bogdandrutu]

Why do you need to know only the service.instance.id and not all the service parts? Per spec service.instance.id is not unique, the combination of the 3 service parts are unique.

[tigrannajaryan]

Why do you need to know only the service.instance.id and not all the service parts? Per spec service.instance.id is not unique, the combination of the 3 service parts are unique.

That's a good point. I was thinking that the extension will get the service name from the BuildInfo (we set service.name to BuildInfo.Command), but this is not the right way, since we now allow it to be overriden.

So you are right, it is best that we make all telemetry attributes available to extensions. Updated the description to make this clear.

[bogdandrutu]

Who provides the configuration? Is not the "OpAMP"? If that is the case you have access to them... Also, they are in the config under service::telemetry::resource, so if you have access to final config you have access to them.

[tigrannajaryan]

Who provides the configuration? Is not the "OpAMP"?

No, "opamp" extension does not provide configuration.

Also, they are in the config under service::telemetry::resource, so if you have access to final config you have access to them.

They are not in the config if the user does not specify them. In that case the Collector generates the id and sets the service name equal to BuildInfo.Command. The "opamp" extension needs access to both of these values.

To make it clear: this feature request is for the situation when there is no Supervisor. You only enable "opamp" extension and it implements a small subset of OpAMP capabilities, mostly status and config reporting. See design doc https://docs.google.com/document/d/1KtH5atZQUs9Achbce6LiOaJxLbksNJenvgvyKLsJrkc/edit

When we have the Supervisor this feature is not necessary.

[srikanthccv]

I was looking for a way to access these attributes for a different reason (specifically in the processor component). @tigrannajaryan I would like to help with this. Since the CreateSettings already embeds the TelemetrySettings, it seems like a good option to provide the resource attributes with it. What do you think?

[tigrannajaryan]

I was looking for a way to access these attributes for a different reason (specifically in the processor component). @tigrannajaryan I would like to help with this. Since the CreateSettings already embeds the TelemetrySettings, it seems like a good option to provide the resource attributes with it. What do you think?

Sounds reasonable to me, but @open-telemetry/collector-maintainers may have other thoughts on what is a good way to address this issue.

[srikanthccv]

@bogdandrutu do you have any thoughts on this?

[evan-bradley]

@bogdandrutu @codeboten I'd like your input on how we can approach this.

In regards to what attributes we make available, I think it would likely make the most sense to provide all resource attributes to extensions. While the OpAMP extension only needs the service attributes, I think other extensions may be able to make use of other resource attributes. If we don't want to provide all resource attributes, I think we should specify the scope of attributes we are willing to provide to extensions.

We can get the attributes in the service from the SDK Resource object that is used to provide resource information to the SDKs. This will also guarantee the extensions and SDKs have the same data.

As for providing this data to extensions, I think passing it under the CreateSettings struct makes the most sense since it will have the same lifecycle as the TelemetrySettings struct.

[codeboten]

Following up on this, there was a discussion about this issue at a SIG call in February where I believe we agreed that the right way to move this forward was to make all resource attributes of the collector available.

Making them available as part of CreateSettings seems like a sensible way to accomplish this.

[jaronoff97]

I'm planning on taking this one, could someone assign to me?

[mx-psi]

Did #7531 fix this issue completely, or is there any remaining work to do here?

[tigrannajaryan]

I haven't verified #7531 but from the description it seems like it should do all that is needed.

[mx-psi]

Alright, seems that way to me as well, closing this then :)