You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However policy self monitor may not be a good place to have these updates as the output bulker health signal is not actually used by the monitor.
Additionally gathering a reference to all bulkers may cause some concurrency issues as seen in #4170.
We may want to have remote bulkers start a heartbeat goroutine that would use the primary bulker to write their status directly; This would address both issues.
The text was updated successfully, but these errors were encountered:
We may want to have remote bulkers start a heartbeat goroutine that would use the primary bulker to write their status directly; This would address both issues.
This is also the first alternative I thought of when I first saw what the code was doing. I don't think we'd have to worry about the number of goroutines, because there aren't going to be 1000s of remote outputs unless there is some crazy bug somewhere.
Describe the enhancement:
Currently remote output health is reported (when
updateState
is called) in the policy-self monitor:fleet-server/internal/pkg/policy/self.go
Lines 262 to 264 in cf41f38
This creates a document in the primary ES instance with the output health status:
fleet-server/internal/pkg/dl/output_health.go
Lines 17 to 41 in cf41f38
However policy self monitor may not be a good place to have these updates as the output bulker health signal is not actually used by the monitor.
Additionally gathering a reference to all bulkers may cause some concurrency issues as seen in #4170.
We may want to have remote bulkers start a heartbeat goroutine that would use the primary bulker to write their status directly; This would address both issues.
The text was updated successfully, but these errors were encountered: