search

open-telemetry / opamp-spec

OpAMP Specification
Apache License 2.0
101 stars 33 forks source link

Agents should report supported components #198

Open andykellr opened 2 weeks ago

andykellr commented 2 weeks ago

I'll describe this in the context of OpenTelemetry, but similar issues will exist for other agents.

OpenTelemetry distributions may have different components included during the build. Before sending a configuration to an agent, the management server will want to know what components are available. Sending a configuration with unsupported components will cause an error. It may be desirable to avoid errors and only allow configurations to be applied to agents that are able to use them.

This is similar to agent capabilities but will need more than a bitmask to support arbitrary component names and versions.

This is similar to what is available in component health, but components not in use (but still supported) would not be reported.

This is similar to package statuses but components are not necessarily packages.

This could be reported with remote configuration but doesn't feel right.

andykellr commented 2 weeks ago

Related issue in the collector: https://github.com/open-telemetry/opentelemetry-collector/issues/10570

andykellr commented 2 weeks ago

We discussed in the SIG meeting that a generic map<string, string> metadata could be added to the AgentDescription message and the structure documented for OpenTelemetry-based agents.

We also discussed making a separate top level AgentMetadata message with a separate agent capability ReportsMetadata.

BinaryFissionGames commented 2 weeks ago

I think logically, you'd consider this part of the AgentDescription. I'd personally advocate for adding it there if possible.

I think the primary advantage we discussed for the separate message was that it did not need to be sent if the OpAMP server does not use it. I'm not sure if that's a huge advantage or not though, given the AgentDescription is generally static over the lifetime of an agent and status compression allows it to be omitted most of the time.

BinaryFissionGames commented 2 weeks ago

Regarding the structure of the field, how would you propose representing the components for the collector in a map[string]string?

Additionally, I feel like arbitrary metadata describing agent is already covered in the identifying/non-identifying attributes, how does this differ?

BinaryFissionGames commented 3 days ago

We discussed this again today at the SIG.

We primarily discussed adding this information to the ComponentHealth message, or to the AgentDescription.