Vector: systemd.socket as source

[gumieri]

Would be interesting to have a systemd.socket as source to the vector.

The advantage of using it instead of listening directly a port is to it "queue" requests if the vector.service is being restarted in case of errors, updating the binary or updating the configurations.

[binarylogic]

@bruceg do you mind reviewing this? Is this something we should do, and does it overlap with the journald source? I don't have enough context on this source to know. Thanks.

[gumieri]

To be fair, it is possible to take advantages of the systemd.socket by configuring a systemd-socket-proxyd, but the option to use the socket more "natively" (a quick search for rust) instead of configuring a proxy sounds great.

It does not overlap journald because it is more like a tcp/udp source integrated with the system for having more resilience decoupling the "listen" responsibility from the service to the systemd, letting the service only with the "serve" responsibility instead of "listen and serve".

[bruceg]

I agree with @gumieri, this does not have any interaction with the journald source. This would be an enhancement to the tcp source (and maybe udp or vector?) to accept a file descriptor passed to it by systemd or systemfd instead of listening for connections directly.

It would be a useful addition for people running systemd. It could allow for restarting Vector without dropping connections.

[binarylogic]

Sounds good, let's proceed then.

[bruceg]

How do we want to handle configuring the listening socket address? When started from systemd, the address setting is overridden by the already created listening socket and so is redundant, but otherwise it is required.

[gumieri]

I think if the systemd.socket would be considered a new sink, the configuration would be just a type (like stdin):

[sources.my_source_id]
  type = "systemd.socket" # must be: "systemd.socket"

But it would be not able to receive metrics from that, only if a statsd transform was also created.

The other strategy would be considering UNIX/IPC socket and systemd.socket as a different kind of address. But, I see it conflicting with tcp and udp source. In that way, would not exist these sources but a raw source and at address to inform if it is a socket or a IP.
TCP Example:

[sources.my_source_id]
  type = "raw"
  address = "0.0.0.0:9000" # as default

UDP example:

[sources.my_source_id]
  type = "raw"
  address = "0.0.0.0:9000/udp"

UNIX Socket example:

[sources.my_source_id]
  type = "raw"
  address = "/tmp/sample.sock"

Systemd Socket example:

[sources.my_source_id]
  type = "raw"
  address = "systemd.socket"

I'm sorry if I am being too intrusive.

[bruceg]

This would not be a new source, but an adaptation of the existing sources that use a common TCP helper module (the syslog, tcp, and vector sources). This could potentially be expanded to other sources that accept connections if the need arises. In this way, it simply becomes a new connection acceptance strategy (which is all this really is), using the same data format handling as the existing sources.