zeekay 67be04e199 feat(zapreceiver): bind a unix socket when Listen is a path ...

All three ZAP receivers narrowed Listen through a port parse into
NodeConfig.Port, which threw the host away and made a socket path
unrepresentable — the receiver could only ever bind TCP. zap already reads an
address's form to choose its network (a leading /, ./, ../ or @ is unix), and
BOTH emit sides already passed the address through untouched, so the receiver
was the only half that could not say "a path". Nothing failed loudly when it
could not: it quietly bound a TCP port instead.

Listen is now passed whole. A host:port still binds TCP, so every off-pod sender
is unaffected — the otel agent on 28 nodes, the gateway, and another cluster
through the otlz door all keep working, and the port parse still refuses a
malformed one. The socket is ADDITIVE; anyone planning to move :4317 onto a
socket instead would take the fleet's telemetry down.

What it buys is the in-pod hop. About 110 plugin processes and the o11y process
share a pod and a run directory, and their telemetry crosses loopback TCP today
for no reason — on an ear bound to 0.0.0.0 that any pod in the cluster can write
to. Over a socket the filesystem's own permissions decide who may write, which
is the discipline the rest of the plane already keeps (0700 directory, 0600
socket, SO_PEERCRED).

uds_test.go pins the property rather than the reading: a path produces a file
that is really a socket AND answers a dial, a port still binds TCP, and a
malformed port is still refused.

2026-08-14 17:42:59 -07:00

..

receiver.go

feat(zapreceiver): bind a unix socket when Listen is a path

2026-08-14 17:42:59 -07:00