데이터 수집 | TAP 미러링 환경에서 Python raw socket으로 syslog 수집 시 중복 발생 원인 분석 및 해결

지난 게시글(https://authentic-information.tistory.com/213)에서 TAP(미러링) 환경에서 Python을 이용해 syslog 데이터를 수집하는 구조를 구현했다.

당시에는 raw socket(AF_PACKET)을 사용해 미러링된 트래픽을 직접 수집하고, 이를 파일로 저장한 뒤 Splunk에서 모니터링하는 방식으로 구성했다. 초기 테스트에서는 정상적으로 데이터가 수집되는 것처럼 보였지만, 실제 운영 데이터를 확인하는 과정에서 예상치 못한 문제가 발생했다.

 

바로 동일한 syslog 이벤트가 여러 번 중복 저장되는 현상이었다.

처음에는 Splunk 파싱 문제나 sourcetype 분기 로직에서의 오류를 의심했지만, 확인을 거듭할수록 문제는 Splunk가 아니라 Python 수집 단계에서 이미 동일 이벤트가 여러 번 기록되고 있는 것으로 보였다.

 

실제 원인은 TAP(미러링) 환경에서 raw socket(AF_PACKET)으로 패킷을 수집하는 구조에 있었다.

이 글에서는 아래 내용을 순서대로 정리한다.

• 중복을 어떻게 발견했는지
• 어떤 명령어로 확인했는지
• 각 결과를 보고 무엇을 판단했는지
• 왜 UDP socket 방식이 실패했는지
• 최종 해결 구조

---

1. 문제 상황

현재 수집 구조는 다음과 같다.

• TAP(미러링) 포트에서 트래픽 복제
• Python이 raw socket으로 패킷 수집
• 파일로 저장 후 Splunk에서 모니터링

s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.ntohs(ETH_P_ALL))
s.bind((IFACE, 0))

 

이 방식은 미러링 환경에서는 필수지만, 동일 패킷이 여러 번 수집되는 문제가 발생할 수 있다.

---

2. 중복 의심

index=kh_* | stats count by index host _raw

 

처음에는 단순히 같은 시간대 이벤트가 많은 것처럼 보였다.

예를 들어:

ACTION=하드웨어정보 수집
ACTION=모니터정보 수집
ACTION=프린터정보 수집

 

이 경우는 정상이다. (서로 다른 이벤트)

---

3. 진짜 중복인지 확인

index=kh_* 
| stats count by _raw
| where count > 1

 

이 쿼리를 사용한 이유:

• 완전히 동일한 로그만 묶기 위해
• 진짜 중복인지 확인하기 위해

결과적으로 동일한 _raw가 여러 번 존재하는 것이 확인되었다.

---

4. 파일 단계에서 확인

Splunk 문제가 아니라 수집 단계 문제인지 확인하기 위해 직접 파일을 조회했다.

grep "192.168.30.119" /data/syslog/... | wc -l

 

결과: 10000건 이상 → 비정상

 

 

정확한 확인을 위해 -F 옵션 사용

grep -F "[15/Apr/2026:17:20:51 +0900],ACCEPT,..." /data/syslog/... | wc -l

 

결과:

6

 

→ 완전히 동일한 이벤트가 6번 기록됨

결론: Python 수집 단계에서 중복 발생

---

5. Docker/네트워크 경로 확인

ip -br addr
ip addr

 

확인 결과:

• docker0 존재
• veth 존재

하지만 실제 패킷 흐름 확인 필요

tcpdump -i eno2 udp port 514 -nn
tcpdump -i docker0 udp port 514 -nn

 

결과:

• eno2 → 패킷 있음
• docker0 → 없음

결론: docker bridge 문제 아님

---

6. UDP socket으로 변경 시도

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("0.0.0.0", 514))

 

결과:

• 중복 사라짐
• 하지만 로그도 사라짐

---

7. tcpdump로 원인 확인

tcpdump -i eno2 port 514 -nn

 

결과:

192.168.3.164 > 192.168.3.157:514

 

중요 포인트:

• 목적지 IP = 192.168.3.157
• 내 서버 IP ≠ 목적지

---

8. 핵심 원인

현재 구조는:

원래 트래픽 → 165.141.3.157
        ↓
TAP 미러링
        ↓
내 서버

 

즉, 나는 수신자가 아니라 패킷 감시자

---

9. 왜 UDP socket이 안 되는가

방식	설명	결과
AF_PACKET	모든 패킷 스니핑	가능
UDP socket	내 IP로 온 패킷만 수신	불가능

 

결론: TAP 환경에서는 UDP socket 사용 불가

---

10. 최종 해결 구조

TAP 트래픽
 → raw socket
 → dedup
 → 파일 저장
 → Splunk

---

11. Splunk 검증 쿼리

중복 확인

index=kh_* 
| stats count by _raw
| where count > 1

수집 경로 확인

index=kh_* 
| stats count by _raw source sourcetype
| where count > 1

---

12. 결론

• Splunk 문제가 아니라 수집기 문제였다
• TAP 환경에서는 raw socket이 필수다
• 중복은 dedup으로 해결해야 한다

---

 

다음 글에서는 이번 문제 해결 과정에서 정리된 내용을 바탕으로,

raw socket 기반 syslog 수집기를 어떤 구조로 설계했고 Python 코드를 어떻게 작성했는지를 상세하게 정리할 예정이다.