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
Opening here for discussion as I imagine this could be quite complicated and I'm not sure if it fits into the vision of Vector or not.
A user brought up the idea of buffering events in a remote storage when a sink is down to be sent when it comes back up.
An alternative, I think, would be to propagate the backpressure to the sources, making them responsible for queuing up messages. I could see for some sources, like the HTTP source, that they may get better behavior allowing Vector to still ingest.
This idea came from gitter: https://gitter.im/timberio-vector/community?at=5f39b2efba27767ee5f5aba0
Opening here for discussion as I imagine this could be quite complicated and I'm not sure if it fits into the vision of Vector or not.
A user brought up the idea of buffering events in a remote storage when a sink is down to be sent when it comes back up.
An alternative, I think, would be to propagate the backpressure to the sources, making them responsible for queuing up messages. I could see for some sources, like the HTTP source, that they may get better behavior allowing Vector to still ingest.
Apparently Matomo has a similar feature where it'll buffer to Redis (or MySQL): https://matomo.org/faq/how-to-update/faq_20844/
Related to the idea of "dead letter queues": #1772
Possibly related, Fluentd's storage plugin architecture: https://docs.fluentd.org/storage ; though I note that only "local" is currently supported.
The text was updated successfully, but these errors were encountered: