私の挑戦
大量のデータの tcpdump を実行する必要があります。実際には、大量のトラフィックを確認できる、プロミスキャス モードのままになっている 2 つのインターフェースから実行する必要があります。
まとめると
- 2 つのインターフェースからのすべてのトラフィックをプロミスキャス モードでログに記録します。
- これらのインターフェースはないIPアドレスを割り当て
- pcapファイルは1Gごとにローテーションする必要がある
- 10TBのファイルが保存されたら、最も古いものから切り捨てを始める
現在行っていること
現在、私は tcpdump を次のように使用しています:
ifconfig ethX promisc
ifconfig ethX promisc
tcpdump -n -C 1000 -z /data/compress.sh -i any -w /data/livedump/capture.pcap $FILTER
には$FILTER
src/dst フィルターが含まれているので、 を使用できます-i any
。 その理由は、インターフェイスが 2 つあり、ダンプを 2 つのスレッドではなく 1 つのスレッドで実行したいからです。
compress.sh
tar を別の CPU コアに割り当て、データを圧縮し、適切なファイル名を付けてアーカイブの場所に移動します。
any
2 つのインターフェースを指定することはできないため、フィルターを使用してインターフェースからダンプすることを選択しました。
今のところ、ハウスキーピングは何もしていませんが、ディスクを監視し、残り 100G になったら最も古いファイルの消去を開始する予定です。これで問題ないはずです。
そして今、私の問題は
ドロップされたパケットが見られます。これは、数時間実行され、約 250 GB の pcap ファイルを収集したダンプからのものです。
430083369 packets captured
430115470 packets received by filter
32057 packets dropped by kernel <-- This is my concern
多数のパケットがドロップされるのを防ぐにはどうすればよいですか?
これらはすでに試したり見たりしたこと
/proc/sys/net/core/rmem_max
との値を変更した/proc/sys/net/core/rmem_default
ところ、確かに効果がありました。実際に、ドロップされたパケットの約半分が処理されました。
私も見てきましたゴクリ- gulp の問題は、1 つのプロセスで複数のインターフェースをサポートしておらず、インターフェースに IP アドレスがない場合に gulp がエラーを起こすことです。残念ながら、私の場合、これが致命的です。
次の問題は、トラフィックがパイプを通過するときに、自動ローテーションを実行できないことです。10 TB の巨大なファイルを 1 つ取得するのはあまり効率的ではなく、Wireshark を実行できる 10 TB 以上の RAM を搭載したマシンがないため、これは不可能です。
何か提案はありますか? トラフィックダンプを全体的に行うための、もっと良い方法があるかもしれません。
答え1
tcpdump は着信データをリング バッファに保存します。tcpdump がバッファの内容を処理する前にバッファがオーバーフローすると、パケットが失われます。
デフォルトのリングバッファサイズはおそらく2048です(2MiB)。
バッファ サイズを増やすには、次の-B
オプションを追加します。
tcpdump -B 4096 ...
より高速なディスク ストレージの使用も検討してください。
答え2
結局、納得のいく解決策を見つけました。ドロップされたパッケージは 0.0047% から 0.00013% に減少しました。これは、最初は大したことではないように思えますが、数百万のパケットの話になると、かなりの数になります。
解決策はいくつかありました。その 1 つは、Michael Hampton の提案に従ってリング バッファのサイズを変更することでした。
また、ramfs を作成してそこにライブ ダンプし、圧縮スクリプトを書き直して、ramfs からディスクへのダンプの移動を処理しました。これにより、量はほんの少ししか減りませんでしたが、注目に値するほどには減りました。ディスクのすべてのテストとベンチマークでは、ディスクがボトルネックになるべきではないことが示されています。ここでは、アクセス時間が非常に重要であると思います。
ハイパースレッディングを無効にすると、予想以上の効果が得られました。