-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[inputs.socket_listener] Metrics size limitations #16082
Comments
@MarekZydor please test the binary in PR #16111, available as soon as CI finished the tests, and let me know if this fixes the issue! |
Hey, that fixed the issue only when I use TCP (SOCK_STREAM). Interestingly, I don't have any problems resending measurements with a length of 200KB to InfluxDB, so that's great. But still, when receiving via UDP (SOCK_DGRAM), I get errors like this:
|
I guess another PR is needed to fix that. |
Could you please report this as a separate bug, best with a way to reproduce the issue! |
New issue created #16118 |
Relevant telegraf.conf
Logs from Telegraf
System info
telegraf 1.32.1, ubuntu 22.04
Docker
No response
Steps to reproduce
You can use the following C++ application to send a metric with very long text
You will get the same behavior when you try to transfer data over TCP, UDP, or Unix Domain Sockets (types SOCK_STREAM - unix and SOCK_DGRAM - unixgram). This problem is not related to IPv4 MTU or buffer sizes, but only to how the plugin was implemented. You could try putting smaller fields that exceed a total of 64 KB, and then you will get the same result.
Expected behavior
Data is correctly parsed and printed to stdout as defined in telegraf.conf
Actual behavior
When TCP (SOCK_STREAM) is used, an error related to Golang's bufio.Scanner is printed.
When UDP (SOCK_DGRAM) is used, an error about being unable to find the end character of a specific field is printed (as shown below):
2024-10-27T22:43:35Z E! [inputs.socket_listener] Error in plugin: metric parse error: expected field at 1:65537: "...skpxcj{part of long text}<-- here
Additional info
For now, I have found a workaround by using http_listener_v2, which is able to parse large metrics. But, I'd like to use UDP in the future.
The text was updated successfully, but these errors were encountered: