我最近在我拥有的 Amazon EC2 debian 实例上安装了netdata。Netdata 非常酷，漂亮的图表/图形，轻松安装（与其他人相比）。
我每天都会多次收到一条消息，例如
1m ipv4 udp receive buffer errors = 9 errors
number of UDP receive buffer errors during the last minute
几分钟后，一条恢复消息。一天中可能有数百个 UDP/TCP 指示的错误。我还在家里运行的服务器上看到了类似的模式。
多年来，我使用过其他监控包，从未见过此类错误。我怀疑某些级别的错误，尤其是在 UDP 上，是正常的，是吗？这是预期的行为吗？我可以关闭对这些警报的监控吗？
我已经搬到家里机器上的第二个网卡，行为没有本质的变化。
在中等规模的环境中，这个可接受的以太网错误数量是多少？表明我可能有严重的问题，我当然可以在家里尝试其他网卡。但是我会在我的 EC2 实例上解决这个问题吗？
可能还值得注意的是 logwatch 根本没有报告任何问题，但是，它可能没有为此进行配置。
谢谢指导。
netdata使用statsd的指标收集系统。这是一个基于 UDP 的协议，它非常快速和高效，但在高速率下可能会溢出入口节点的 recv_buffer。默认接收缓冲区大约为 1M - 所以如果 statsd 代理不能足够快地消耗以防止缓冲区填满，内核将丢弃数据报。
简单的解决方案是将您的 recv 缓冲区增加到更大的大小以处理峰值 - 这通常解决了 UDP 缓冲区溢出的问题。如果您仍然看到上面的日志，您将需要增加机器的 CPU 容量或转向性能更高的 statsd 实现（我们不得不从基于标准 nodejs 的 statsd 客户端移动到基于 C++ 的客户端）。
要增加缓冲区大小，请使用以下命令：
# echo "net.core.rmem_default=8388608" >> /etc/sysctl.conf
# echo "net.core.rmem_max=16777216" >> /etc/sysctl.conf
# sysctl -p
上述参数非常激进，会增加内核堆栈的内存使用量。您可能希望从较小的值开始并从那里增加 - 传统比率是max = default * 2。
更多信息请访问：https : //www.ibm.com/support/knowledgecenter/en/SSQPD3_2.6.0/com.ibm.wllm.doc/UDPSocketBuffers.html