-
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
Fix udp metric splitting #2880
Fix udp metric splitting #2880
Conversation
This is done by the Reader later on.
Sure, we can do that. If anything, let's add a crazy long testcase to the UDP endpoint no? |
Here's one for the tests...
|
Deployed it on a test node and the drops that I saw previously are not to be seen. For checking the dops I'm generating a super-simple "heartbeat" metric and looking what comes out the other side:
The metrics look sane in tcpdump and none of the other parts of our metrics pipeline are reporting errors. I'll keep an eye on it though. |
(cherry picked from commit 5bab461)
(cherry picked from commit 5bab461)
Another attempt at fixing #2862
This fixes several length checks and a state transition in metric reader and removes previous change to split in influxdb.go. The reader bugs could cause the reader to enter the overflow and splitOverflow states unnecessarily. These states will split metrics at positions that are illegal for udp.
In the influxdb udp client, I take advantage of the fact that the reader returns points one at a time to verify a full line was read and only send if this is true. Only points that are longer than the udp payload size should be a problem. They are logged and discarded.
A better fix would maybe be building this into the Reader, so that it is packet aware, or perhaps the Reader interface is just the wrong fit here. Relying on the reader to return points one at a time is not a very robust solution.
cc @sebito91
Required for all PRs: