A note for the community
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Right now vector has "vector" sink that allows you to send metrics and logs to another instance, however sometimes it is useful to have a pull model where vector agent that collects logs and metrics from the node starts listening on tcp port and when another vector instance connects to it, agent starts streaming all events same way it does now. This would allow deploying vector-aggregator after vector-agent.
Use Cases
Example of use case is deployment of vector-agent as systemd unit on the nodes and then deployment of vector-aggregator through helm to kubernetes cluster on this nodes to collect events from all agents and send them to centralized storage like clickhouse, elasticsearch, etc.
At the time when vector-agent starts first time, vector-aggregator does not exist yet, therefore process will fail. With new proposed sink option or separate sink, it will just start listening on port, waiting for vector-aggregator to connect to it before starting streaming events.
Attempted Solutions
I don`t think it is possible to cleanly solve this right now using existing sinks because they are all built around push model, where agent pushes events to aggregator, therefore agent expects aggregator to exist before it starts.
Proposal
I think the best way to resolve this is to add option mode to both vector sink and source where two allowed values are "connect" "wait-for-connect". If agent vector sink is "connect" and aggregator vector source is "wait-for-connect" then we have current default behaviour. However if agent vector sink is "wait-for-connect" and aggregator vector source is "connect" then roles reverse, agent listens on socket and aggregator connects to it, after which logic is identical: agent streams all events to aggregator.
References
No response
Version
vector 0.54.0 (x86_64-unknown-linux-gnu 2b8b875 2026-03-10 15:47:37.284215410)
A note for the community
Right now vector has "vector" sink that allows you to send metrics and logs to another instance, however sometimes it is useful to have a pull model where vector agent that collects logs and metrics from the node starts listening on tcp port and when another vector instance connects to it, agent starts streaming all events same way it does now. This would allow deploying vector-aggregator after vector-agent.
Use Cases
Example of use case is deployment of vector-agent as systemd unit on the nodes and then deployment of vector-aggregator through helm to kubernetes cluster on this nodes to collect events from all agents and send them to centralized storage like clickhouse, elasticsearch, etc.
At the time when vector-agent starts first time, vector-aggregator does not exist yet, therefore process will fail. With new proposed sink option or separate sink, it will just start listening on port, waiting for vector-aggregator to connect to it before starting streaming events.
Attempted Solutions
I don`t think it is possible to cleanly solve this right now using existing sinks because they are all built around push model, where agent pushes events to aggregator, therefore agent expects aggregator to exist before it starts.
Proposal
I think the best way to resolve this is to add option mode to both vector sink and source where two allowed values are "connect" "wait-for-connect". If agent vector sink is "connect" and aggregator vector source is "wait-for-connect" then we have current default behaviour. However if agent vector sink is "wait-for-connect" and aggregator vector source is "connect" then roles reverse, agent listens on socket and aggregator connects to it, after which logic is identical: agent streams all events to aggregator.
References
No response
Version
vector 0.54.0 (x86_64-unknown-linux-gnu 2b8b875 2026-03-10 15:47:37.284215410)