Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: remote buffer #3485

Closed
jszwedko opened this issue Aug 17, 2020 · 1 comment
Closed

Idea: remote buffer #3485

jszwedko opened this issue Aug 17, 2020 · 1 comment
Labels
needs: requirements Needs a a list of requirements before work can be begin

Comments

@jszwedko
Copy link
Member

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.

@jamtur01 jamtur01 added the needs: requirements Needs a a list of requirements before work can be begin label Sep 29, 2020
@binarylogic
Copy link
Contributor

Closing in favor of #5463

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs: requirements Needs a a list of requirements before work can be begin
Projects
None yet
Development

No branches or pull requests

3 participants