Closed bazko1 closed 1 week ago
Hi,
@srebhan thoughts on this one? I think it would be preferred to do this in the socket listener plugin, but are there barriers to that?
Apart from adding unix_socket parameter this would probably also require adding flag for controlling socket permission mode could be done similarly like in socket_listener -> socket_mode
The unix_socket param should not be a boolean, can't this be the "network", which defaults to "tcp", an a user can set this to http?
After talking about this, I think @srebhan will take a look, but would be happy to see a PR extending the http listener plugin. I would again avoid the boolean config option and instead make it an option to select the network type possible or something similar.
Use Case
Since libcurl 7.40.0 it allows to perform HTTP requests over unixsocket. I would like to push messages into telegraf from external tools over HTTP without TCP listening over localhost. Unix sockets will allow me to enforce user/group file permissions and more easily restrict access to pushing metrics for specific users.
I have already made local changes and they seem pretty small to achieve the result. My proposition is to add new boolean option
unix_socket
. It would makeservice_address
interpreted as unix socket path. Sample configuration:This would allow one to push messages for example via curl:
curl -X PUT --unix-socket ./test.sock http://localhost:8080/telegraf -d '{"foo":10}'
I have seen that following feature was already added for HTTP collecting plugins: 11038
I have tried to achieve the same result using
input.socket_listener
, but it seems not doable as there is no easy way to split HTTP header part from its body so that only message is interpreted by plugin.Apart from adding
unix_socket
parameter this would probably also require adding flag for controlling socket permission mode could be done similarly like insocket_listener
->socket_mode
Let me know what you think about this feature and I would be happy to create PR with changes.
Expected behavior
Possibility to push HTTP messages over unix socket.
Actual behavior
Current call for
Listen
is fixed to "tcp" providing unix path instead of address:port will result in error.Additional info
No response