最近インストールしたネットデータ私が所有する Amazon EC2 Debian インスタンスで。Netdata は非常に優れており、チャートやグラフも優れており、インストールも非常に簡単です (他のものと比べて)。
毎日何度も次のようなメッセージを受け取ります
1m ipv4 udp receive buffer errors = 9 errors
number of UDP receive buffer errors during the last minute
そして数分後には回復メッセージが表示されます。おそらく、UDP/TCP では 1 日を通して何百ものエラーが示されるでしょう。自宅で稼働しているサーバーでも同様のパターンが見られます。
私は長年他の監視パッケージを使用してきましたが、このタイプのエラーは見たことがありません。特に UDP では、ある程度のエラーは正常であると思われますが、これは正しいでしょうか? これは予想される動作ですか? これらのアラームの監視をオフにできますか?
自宅のマシンで 2 番目の NIC に移行しましたが、動作に本質的な変化はありませんでした。
これ中規模環境で許容されるイーサネット エラーの数はどれくらいですか?深刻な問題がある可能性があることを示唆しており、自宅で他の NIC を試すことはできます。しかし、EC2 インスタンスでこれを解決するにはどうすればよいですか?
また、logwatch がまったく問題を報告しないことにも注目すべきですが、そのために構成されていない可能性があります。
ご指導ありがとうございます。
答え1
netdataメトリック収集システムとして使用しますstatsd。これは、非常に高速で効率的な UDP ベースのプロトコルですが、レートが高いと、イングレス ノードの recv_buffer がオーバーフローする可能性があります。デフォルトの受信バッファは約 1M です。そのため、statsd エージェントがバッファがいっぱいにならないように十分な速さで消費できない場合、カーネルはデータグラムをドロップします。
簡単な解決策は、スパイクを処理するために受信バッファを大きくすることです。これにより、通常、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