Мой вызов
Мне нужно выполнить tcpdumping большого объема данных — фактически с двух интерфейсов, оставленных в неразборчивом режиме, которые могут видеть большой объем трафика.
Подвести итог
- Регистрировать весь трафик в смешанном режиме с 2 интерфейсов
- Эти интерфейсынетназначен IP-адрес
- Файлы pcap должны быть ротированы на ~1G
- Когда объем сохраненных файлов достигнет 10 ТБ, начните обрезать самые старые.
Чем я сейчас занимаюсь
Сейчас я использую 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. Причина в том, что у меня два интерфейса, и я хотел бы запустить дамп в одном потоке, а не в двух.
compress.shпозаботится о назначении tar другому ядру ЦП, сожмет данные, даст им разумное имя и переместит их в архивное местоположение.
Я не могу указать два интерфейса, поэтому я решил использовать фильтры и выгрузить данные с anyинтерфейса.
Сейчас я не занимаюсь уборкой, но планирую следить за диском, и когда у меня останется 100 ГБ, я начну стирать самые старые файлы — этого должно быть достаточно.
И теперь моя проблема
Я вижу потерянные пакеты. Это из дампа, который работал несколько часов и собрал около 250 гигабайт 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 в том, что он не поддерживает несколько интерфейсов в одном процессе и злится, если у интерфейса нет IP-адреса. К сожалению, в моем случае это является решающим фактором.
Следующая проблема в том, что когда трафик идет через канал, я не могу запустить автоматическую ротацию. Получение одного огромного файла на 10 ТБ не очень эффективно, и у меня нет машины с 10 ТБ+ ОЗУ, на которой я мог бы запустить Wireshark, так что это отпадает.
Есть ли у вас какие-либо предложения? Может быть, даже лучший способ сделать мой трафик-свалку в целом.
решение1
tcpdump сохраняет входящие данные в кольцевом буфере. Если буфер переполнится до того, как tcpdump обработает его содержимое, вы потеряете пакеты.
Размер кольцевого буфера по умолчанию, вероятно, составляет 2048.(2МиБ).
Чтобы увеличить размер буфера, добавьте -Bопцию:
tcpdump -B 4096 ...
Вам также следует попробовать использовать более быстрое дисковое хранилище.
решение2
В итоге я нашел решение, с которым можно жить. Количество потерянных пакетов сократилось с .0047% до .00013% — на первый взгляд это не так уж много, но когда речь идет о миллионах пакетов, это довольно много.
Решение состояло из нескольких вещей. Одной из них было изменение размера кольцевого буфера, как предложил Майкл Хэмптон.
Также я создал ramfs и сделал live dumping в него, переписал свой скрипт сжатия, чтобы позаботиться о перемещении дампов из ramfs на диск. Это уменьшило объем совсем немного, но достаточно, чтобы это было заметно - хотя все тестирования и бенчмарки диска показывают, что диск не должен быть узким местом. Я думаю, время доступа здесь очень важно.
Отключение Hyper-Threading также дало больше, чем вы думали.