나의 도전
많은 양의 데이터를 tcpdumping해야 합니다. 실제로는 많은 트래픽을 볼 수 있는 무차별 모드에 남아 있는 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. 그 이유는 두 개의 인터페이스가 있고 두 개가 아닌 단일 스레드에서 덤프를 실행하고 싶기 때문입니다.
compress.shtar를 다른 CPU 코어에 할당하고, 데이터를 압축하고, 적절한 파일 이름을 지정하고 아카이브 위치로 이동합니다.
두 개의 인터페이스를 지정할 수 없으므로 필터를 사용하고 any인터페이스에서 덤프하도록 선택했습니다.
지금은 어떤 관리 작업도 하지 않지만 디스크를 모니터링할 계획이며 100G가 남으면 가장 오래된 파일을 지우기 시작할 것입니다. 이 정도는 괜찮을 것입니다.
그리고 지금; 내 문제
삭제된 패킷이 보입니다. 이것은 몇 시간 동안 실행되어 대략 250GB의 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 주소가 없으면 화가 난다는 것입니다. 불행히도 그것은 내 경우에는 거래 차단기입니다.
다음 문제는 교통이 파이프를 통해 흐를 때 자동 회전을 할 수 없다는 것입니다. 하나의 거대한 10TB 파일을 얻는 것은 그리 효율적이지 않으며 Wireshark를 실행할 수 있는 10TB 이상의 RAM이 있는 시스템이 없기 때문에 종료되었습니다.
의견 있으십니까? 어쩌면 트래픽 덤프를 모두 수행하는 더 좋은 방법일 수도 있습니다.
답변1
tcpdump는 들어오는 데이터를 링 버퍼에 저장합니다. tcpdump가 내용을 처리하기 전에 버퍼 오버플로가 발생하면 패킷이 손실됩니다.
기본 링 버퍼 크기는 아마도 2048일 것입니다.(2MiB).
버퍼 크기를 늘리려면 다음 -B옵션을 추가하세요.
tcpdump -B 4096 ...
또한 더 빠른 디스크 저장소를 사용해 보아야 합니다.
답변2
나는 결국 함께 살 수 있는 해결책을 찾았습니다. 삭제된 패키지가 .0047%에서 .00013%로 감소했습니다. 처음에는 그다지 많아 보이지 않지만, 수백만 개의 패킷을 이야기하면 꽤 많은 양입니다.
해결책은 여러 가지로 구성되었습니다. 하나는 Michael Hampton이 제안한 대로 링 버퍼 크기를 변경하는 것이었습니다.
또한 ramfs를 생성하고 이에 대한 라이브 덤프를 수행했으며, 덤프를 ramfs에서 디스크로 이동하는 작업을 처리하기 위해 압축 스크립트를 다시 작성했습니다. 이로 인해 양이 아주 적게 감소했지만 주목할 만큼 충분했습니다. 디스크에 대한 모든 테스트 및 벤치마킹에서 디스크가 병목 현상을 일으키지 않아야 함을 보여주더라도 말입니다. 여기서는 접근 시간이 매우 중요하다고 생각합니다.
하이퍼 스레딩을 비활성화하는 것도 생각보다 더 많은 일을 했습니다.