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
Describe the bug
The gateway or the collector process may be killed for various reason in a shared environment (even if we assign a request to memory). During the restart of the collector process, the instrumentor removes the instrumentation from all instrumented applications and after the collector come back it adds it back again.
This is fairly disruptive, especially in a cluster with several applications that have relatively heavy startup load (like java applications), restarting every instrumented app (potentially twice) all at the same time creates even more problems and potentially kill again the collector, causing some significant, maybe even ongoing churn.
To Reproduce
Create an environment with somewhat limited (or well sized?) resources, where the applications can all run at the same time as well as the odigos pipeline, but occasional spike can disrupt one or so process (which by itself should be able restart without impacting others).
Expected behavior
Tolerate disruptions in the pipeline, maybe wait before uninstrumenting applications and even then possible stagger the instrumentation/uninstrumentation
Additional context
We also discussed besides adding a memory limiter also setting a default (and configurable) request/limit on the collector. Which is good, but does not completely guarantee no disruptions.
The text was updated successfully, but these errors were encountered:
Describe the bug
The gateway or the collector process may be killed for various reason in a shared environment (even if we assign a request to memory). During the restart of the collector process, the instrumentor removes the instrumentation from all instrumented applications and after the collector come back it adds it back again.
This is fairly disruptive, especially in a cluster with several applications that have relatively heavy startup load (like java applications), restarting every instrumented app (potentially twice) all at the same time creates even more problems and potentially kill again the collector, causing some significant, maybe even ongoing churn.
To Reproduce
Create an environment with somewhat limited (or well sized?) resources, where the applications can all run at the same time as well as the odigos pipeline, but occasional spike can disrupt one or so process (which by itself should be able restart without impacting others).
Expected behavior
Tolerate disruptions in the pipeline, maybe wait before uninstrumenting applications and even then possible stagger the instrumentation/uninstrumentation
Additional context
We also discussed besides adding a memory limiter also setting a default (and configurable) request/limit on the collector. Which is good, but does not completely guarantee no disruptions.
The text was updated successfully, but these errors were encountered: