Relevant telegraf.conf
[[outputs.prometheus_client]]
## Run on a guest whose context ID is 3, but name the host CID
listen = "vsock://2:9273"
Logs from Telegraf
2026-09-22T09:00:00Z I! [outputs.prometheus_client] Listening on http://vm(3):9273/metrics
The log line shows the bound context ID, but the address is accepted and no warning says the configured CID was dropped.
System info
Telegraf 1.40.1, Linux with vsock
Docker
No response
Steps to reproduce
- Run Telegraf in a VM whose context ID is not the one in the address, e.g. a guest with CID 3.
- Configure
listen = "vsock://2:9273", so the CID names the host rather than the guest.
- Start Telegraf and check what the listener bound, e.g.
ss -l --vsock.
Expected behavior
Either the listener binds the CID given in the address, or Telegraf rejects the address at startup because that CID is not ours. The plugin knows both before any scrape arrives.
Actual behavior
listenVsock in plugins/outputs/prometheus_client/prometheus_client.go splits the address with net.SplitHostPort and discards the host half, then calls vsock.Listen(port, nil), which binds the context ID of the machine Telegraf runs on. The listener in the example comes up on CID 3 while the config says 2, and a scraper addressing CID 2 never reaches it.
Additional info
The documented form is listen = "vsock://:9273" with no CID, and for that form binding the local context ID is correct, so this only bites the undocumented spelling that carries one. Honoring it with vsock.ListenContextID when the host part is non-empty would match inputs.socket_listener (#19751) and outputs.socket_writer, which passes the CID to vsock.Dial. A CID that is not ours would then fail at startup with EADDRNOTAVAIL rather than binding something else, which is the behavior change to call out in the CHANGELOG.
Same class as #19751, but a separate code path and a separate decision, since here the empty CID is the documented default.
Relevant telegraf.conf
Logs from Telegraf
The log line shows the bound context ID, but the address is accepted and no warning says the configured CID was dropped.
System info
Telegraf 1.40.1, Linux with vsock
Docker
No response
Steps to reproduce
listen = "vsock://2:9273", so the CID names the host rather than the guest.ss -l --vsock.Expected behavior
Either the listener binds the CID given in the address, or Telegraf rejects the address at startup because that CID is not ours. The plugin knows both before any scrape arrives.
Actual behavior
listenVsockinplugins/outputs/prometheus_client/prometheus_client.gosplits the address withnet.SplitHostPortand discards the host half, then callsvsock.Listen(port, nil), which binds the context ID of the machine Telegraf runs on. The listener in the example comes up on CID 3 while the config says 2, and a scraper addressing CID 2 never reaches it.Additional info
The documented form is
listen = "vsock://:9273"with no CID, and for that form binding the local context ID is correct, so this only bites the undocumented spelling that carries one. Honoring it withvsock.ListenContextIDwhen the host part is non-empty would matchinputs.socket_listener(#19751) andoutputs.socket_writer, which passes the CID tovsock.Dial. A CID that is not ours would then fail at startup withEADDRNOTAVAILrather than binding something else, which is the behavior change to call out in the CHANGELOG.Same class as #19751, but a separate code path and a separate decision, since here the empty CID is the documented default.