enhancement(networking): Add support for systemd socket activation

[bruceg]

This adds support for systemd socket activation to all the sources that use the TcpSource framework. That is, the syslog, tcp, and vector sources. It adds support for a new address type that indicates the socket is being passed in by systemd (or equivalent).

Closes #950

I am not particularly comfortable with the systemd#N address syntax, but it was the best compromise I could think up. It is possible to autodetect when socket activation is in play, but since both Vector and systemd support multiple sockets, this creates an ambiguity with the order in which the sockets are used. I welcome alternate suggestions how to make it work better.

I have tested this on the command line using systemfd, but no automated tests are present other than address parsing.

[bruceg]

As this has impact on multiple sources, I was unclear what a proper semantic PR title would look like.

[binarylogic]

Yeah, I wish we could provide multiple, comma-separated scopes. Technically we could support that and deviate from the spec.

[binarylogic]

One thing I'd like to do address in the docs is the distinction between this and the systemd source, or at least a callout in the systemd source that systemd sockers can be used in the tcp and vector sources.

[binarylogic]

And this might be a dumb question, but is the udp source not relevant here? (apologies for the multiple comments)

[bruceg]

is the udp source not relevant here?

There is no reason why not, other than that I had limited my implementation to the common TcpSource framework. Extending it beyond should be straightforward now that those bits are working.

[bruceg]

One thing I'd like to do address in the docs is the distinction between this and the systemd source, or at least a callout in the systemd source that systemd sockers can be used in the tcp and vector sources.

We don't actually have a systemd source, so I assume you're referring to the journald source. Is this still relevant there?

[binarylogic]

We don't actually have a systemd source, so I assume you're referring to the journald source. Is this still relevant there?

Ha, you're right. It's somewhat relevant given that the 2 are tightly coupled, but less so now.

[lukesteensen]

Nice! This is even cleaner than I expected.

Small nitpick: should we give "systemd" as an example for all of the sources instead of just "systemd#2"? I feel like the basic version will likely be more common.

[bruceg]

Small nitpick: should we give "systemd" as an example for all of the sources instead of just "systemd#2"? I feel like the basic version will likely be more common.

I was actually hoping for advice on that, or if the whole "systemd" bit was the wrong approach to begin with. If you think the simple form is a better example, then simple it is.

[lukesteensen]

I like where you ended up with that! It seems relatively simple and unambiguous, and I would assume that in most cases users will only need the systemd version. The #N suffix also seems like a straighforward way to handle cases where they're passing multiple. I think it's good to give examples of both.

[bruceg]

@binarylogic to what do I need to change the title on this to make it a valid semantic PR title?

[binarylogic]

Hey @bruceg , you just need to pick a valid scope here:

https://github.com/timberio/vector/blob/b6a8778949d9fbb36637bec13bf9a9b03762663b/.github/semantic.yml#L12

I'd probably just use networking for now.