![netdata ipv4 UDP 错误](https://linux22.com/image/718329/netdata%20ipv4%20UDP%20%E9%94%99%E8%AF%AF.png)
我最近安装了网络数据在我拥有的 Amazon EC2 debian 实例上。Netdata 非常酷,图表/图形很漂亮,安装起来非常轻松(与其他产品相比)。
我每天都会收到很多这样的信息
1m ipv4 udp receive buffer errors = 9 errors
number of UDP receive buffer errors during the last minute
几分钟后,出现一条恢复消息。一天中可能出现数百个 UDP/TCP 错误。我在家里运行的服务器上也看到了类似的模式。
多年来,我一直使用其他监控包,从未见过这种类型的错误。我怀疑某种程度的错误(尤其是 UDP 上的错误)是正常的,对吗?这是预期的行为吗?我可以关闭这些警报的监控吗?
我已经将家里的机器转移到第二个 NIC,但行为没有发生本质变化。
这中型环境中可接受的以太网错误数量是多少?这表明我可能遇到了严重的问题,我当然可以在家里尝试其他 NIC。但我该如何在我的 EC2 实例上解决这个问题呢?
也许还值得注意的是,logwatch 报告根本没有问题,但是,它可能没有为此配置。
谢谢您的指导。
答案1
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