Closed cforce closed 1 month ago
Pinging code owners:
cmd/opampsupervisor: @evan-bradley @atoulme @tigrannajaryan
See Adding Labels via Comments if you do not have permissions to add labels yourself.
You mean when the connection to oapserver fails supervisor should exit the process?
The opposite- it shall never exi but retry to re/connect forever
The opposite- it shall never exi but retry to re/connect forever
+1. This is the intent.
Will that MR solve it? Seems like @tigrannajaryan review in on your side ;)
https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/33275
Component(s)
cmd/opampsupervisor
What happened?
Supervisor when started shall not give up to connect to the opamp backend, when errors with connectivity. At least we shall be able to configure the timeout before giving up. In term of resilience in a non stable (e.g. cellular) network environment this would need elsewise a external scheduler like systemd to restart instead of retries of the supervisor itself. such external restart would also increase load on the cpu. A "endless" loop with retry timeout is the best practice for client to sever communication retrs.
Despite the errors, the log indicates that there are retries happening (e.g., will retry message). However, if it seems like it's not retrying, it might be due to:
Immediate Failures: The connection attempts might be failing too quickly in succession, making it appear as if there's no retry mechanism. There might be configuration settings limiting or controlling the retry behavior which i don't know. Why does the supervisor's has such fixed (instead of unlimited) retry policies or limits? I feel the supervisor code is written like that to handle error situation, but it shall retry resilient
Collector version
o.101
Environment information
No response
OpenTelemetry Collector configuration
No response
Log output
Additional context
No response