Component(s)
No response
Describe the issue you're reporting
The opamp-bridge reports itself as a single opamp-agent in the operator mode and pushes all CRs managed by the operator as config files for the same agent. While this makes sense from the operator point of view, it doesn't map well to opamp servers. Servers care about individual otel agents. They want to see collectors, agents, gateways, etc as separate entities with their own config. They might have special features or automations built in to handle these agents differently. Since opamp config file cannot have any kind of metadata other than the file name and body, it is very hard for the server to identify which config file represents which otel agent. It could rely on some naming convention or try to parse the config and make a best guess but all such techniques will be brittle and vary across orgs.
Reporting each managed CR as a separate opamp-agent completely solves this as each agent can have its own metadata that servers can use to identify the role. This also make health reporting work well with opamp servers as each agent can have its own health which makes more sense logically.
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.
Component(s)
No response
Describe the issue you're reporting
The opamp-bridge reports itself as a single opamp-agent in the operator mode and pushes all CRs managed by the operator as config files for the same agent. While this makes sense from the operator point of view, it doesn't map well to opamp servers. Servers care about individual otel agents. They want to see collectors, agents, gateways, etc as separate entities with their own config. They might have special features or automations built in to handle these agents differently. Since opamp config file cannot have any kind of metadata other than the file name and body, it is very hard for the server to identify which config file represents which otel agent. It could rely on some naming convention or try to parse the config and make a best guess but all such techniques will be brittle and vary across orgs.
Reporting each managed CR as a separate opamp-agent completely solves this as each agent can have its own metadata that servers can use to identify the role. This also make health reporting work well with opamp servers as each agent can have its own health which makes more sense logically.
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it. Learn more here.