Remote management for the server

[Doron-Bargo]

Use case - an observability company can offer a "satellite" solution ( like Red hat satellite )

Why it needed:

• Reduce the load on the company backend where they need to maintain millions of web sockets to their customers
• Improve security on the customer side that only 1 server need to open a web socket outside of the company network.

Idea to implement: The server will also implement the opamp mechanism where Server A ( on the SaaS company ) speak with Server B ( that has opamp client as part of it ). Server B speak with all agents on the customer's network.

Things to take in consideration :

• All communication between the Server and the agents should be also forward ( as updates ) to other Server ( in my example Server A )
• Update to the agents can be initiated from Server A or Server B

[tigrannajaryan]

All communication between the Server and the agents should be also forward ( as updates ) to other Server ( in my example Server A )

Yes, proxying OpAMP requests was in the early versions of the spec draft, but removed for now to reduce the scope for 1.0 release. For plain http transport proxying is likely straightforward: it will be plain old http proxy. For websocket transport it can be done in a more efficient way, by concentrating incoming connections to a single outgoing connection. This is doable and the design makes it possible since all messages include agent id explicitly, which allows to multiplex them in one websocket connection.

Update to the agents can be initiated from Server A or Server B

This likely needs to be either Server A or Server B, otherwise it may result in conflicting instructions going to the agents.

This same architecture can be also used for example for Otel Helm Chart, where we have one Otel Collector as an agent on each K8s node and another Otel Collector as an intermediary gateway. The intermediary gateway can also serve as an OpAMP proxy.