로그 회전과 수집기: inode·offset·손실 경계

01개념과 구성 요소

• 로그 회전계속 자라는 로그를 보존 정책에 맞게 나누는 작업이며 writer와 reader의 파일 상태가 함께 바뀐다.
• 식별 요소경로·inode·열린 파일 디스크립터·읽은 offset은 서로 다른 값이다.
• 핵심 위험이름 변경·잘라내기·재시작 사이에서 미수집 꼬리, 중복, 복구 불가능한 손실이 생길 수 있다.

02rename 회전에서 수집 파일을 전환하는 순서

1. 기존 파일 읽기writer와 reader가 기존 inode를 사용하며 reader는 처리한 offset을 추적한다.
2. 이름 변경기존 로그를 회전 이름으로 옮겨도 이미 열린 FD는 기존 inode를 계속 가리킬 수 있다.
3. 새 파일 생성·재열기새 경로의 파일을 만들고 writer가 지원하는 reopen 절차로 새 inode에 쓰도록 전환한다.
4. 이전 파일 마무리reader가 기존 inode의 남은 기록을 끝까지 수집한다. 새 경로만 즉시 따라가면 꼬리 부분을 놓칠 수 있다.
5. 새 파일 추적새 inode의 offset을 별도로 추적하고 전달·저장 확인 문맥과 함께 복구 상태를 유지한다.

03수집 파이프라인과 회전 경계

• 수집 구조원본 ALPACA 프로젝트에서는 Snort가 alert_fast.txt에 경보를 쓰고 Python 수집기가 새 줄을 읽어 DataBuffer에 보낸 뒤 중앙 SIEM으로 전송했다. 로그 파일이 계속 커지므로 logrotate로 크기와 보관 기간을 관리했다.
• 회전 경계여기서 회전은 디스크 정리만이 아니라 쓰는 프로그램과 읽는 프로그램이 어느 파일을 보고 있는지를 바꾸는 사건이다.
• 경로와 상태파일에서 경보 한 줄을 놓친 것과 네트워크 패킷을 캡처하지 못한 것은 서로 다른 손실이다. 경보 파일 회전 문제는 이미 만들어진 경보 기록을 수집하는 단계의 누락이다.
• 패킷 손실과 구분Snort 경보 수, 수집기 전송 수, 중앙 적재 수를 나눠야 패킷 처리 성능 문제와 혼동하지 않는다.
• 손실 추적원본은 작은 규모의 MVP에서 copytruncate를 선택하고 크기가 읽기 위치보다 작아지면 처음부터 다시 읽도록 보완했다. 이것은 알려진 손실 구간을 줄이는 선택이며 무손실 수집을 증명하는 방식은 아니다.

04경로·inode·파일 디스크립터·offset의 관계

• 파일명과 Inode파일명은 디렉터리에서 파일 객체를 찾는 이름이다. 프로세스가 open으로 얻은 파일 디스크립터는 열린 파일을 참조하며, 읽기 위치인 offset은 어느 바이트까지 읽었는지를 나타낸다.
• 열린 FD같은 경로에 새 파일을 만들더라도 이미 열린 디스크립터가 자동으로 새 파일로 이동하지 않는다.
• 파일 정체성Linux의 파일 신원을 추적할 때는 inode만이 아니라 장치 번호와 함께 본다. inode는 삭제 후 재사용될 수 있고 재시작 뒤 파일이 달라질 수 있으므로 영구적으로 유일한 이벤트 식별자로 삼지 않는다.
• 읽은 Offset수집기는 열린 대상의 fstat과 경로의 stat을 비교하여 이름 교체와 내용 축소를 구분할 수 있다.
• 부분 줄줄 기반 수집에서는 마지막 줄의 줄바꿈이 아직 기록되지 않았을 수 있다. 읽은 바이트를 즉시 완성 이벤트로 취급하면 나중에 이어진 내용과 분리된다.
• 미완성 기록부분 줄 버퍼와 마지막으로 확정한 위치를 함께 관리한다.

05rename 방식: 이전 파일을 끝까지 읽고 새 파일로 전환

• Rename일반적인 회전은 현재 파일을 다른 이름으로 바꾸고 원래 경로에 새 파일을 생성한다. 기존 writer의 디스크립터는 이름이 바뀐 옛 파일을 계속 가리킨다.
• Writer Reopen프로그램이 지원하는 reopen 또는 적절한 신호를 통해 새 파일을 열게 해야 하며, 프로그램마다 지원 방식이 다르므로 신호 이름을 공통 답으로 외우지 않는다.
• Reader 전환수집기도 경로가 바뀌자마자 옛 파일을 닫으면 그 사이에 writer가 쓴 끝부분을 놓칠 수 있다. 옛 파일의 남은 데이터를 읽고 writer 전환을 고려한 뒤 새 inode의 파일을 0부터 읽는다.
• 꼬리 보존여러 번 빠르게 회전하거나 재시작하면 상태 저장과 파일 탐색 정책이 필요하다.

06copytruncate 방식과 피할 수 없는 경쟁 구간

• Copytruncatecopytruncate는 현재 내용을 보관 파일로 복사한 뒤 원래 파일 길이를 0으로 줄인다. 열린 디스크립터와 inode를 유지할 수 있어 reopen을 지원하지 않는 writer에도 적용하기 쉽다.
• 손실 창그러나 복사와 truncate는 하나의 원자적 동작이 아니다. 두 동작 사이에 추가된 기록이 보관 사본에 없고 원본에서도 지워질 수 있다.
• 크기 역전수집기가 fsize < offset을 발견해 seek(0)을 하면 축소 후 새로운 기록을 다시 읽을 수 있다. 하지만 검사 사이에 파일이 0으로 줄었다가 기존 offset 이상으로 빠르게 자라면 크기 비교만으로 축소를 놓친다.
• 복구 한계중간에 지워진 데이터를 seek로 복원할 수도 없다.
• 경쟁 예설명용으로 복사가 바이트 1,000까지 끝난 뒤 writer가 100바이트를 더 기록하고 truncate가 실행되었다고 하자. 보관 사본에는 첫 1,000바이트만 있고 원본은 비므로 마지막 100바이트는 다른 곳에 보존하지 않았다면 사라진다. 이 손실을 “수집기에서 크기만 검사하면 해결”이라고 적지 않는다.

1. 기존 내용 복사현재 로그의 내용을 회전 사본으로 복사한다. Writer는 같은 원본 파일에 계속 쓸 수 있다.
2. 원본 잘라내기기존 파일을 truncate하여 같은 inode의 크기를 줄인다.
3. Reader 감지수집기는 크기가 offset보다 작아졌는지 등으로 변화를 감지하고 읽기 상태를 조정한다.
4. 손실 경계 확인복사와 truncate 사이의 기록은 사본에 없으면서 원본에서 사라질 수 있다. 사후 offset 복구만으로 이 구간을 되살릴 수는 없다.

07logrotate 옵션의 의미

• Dailydaily는 실행될 때 일 단위 조건을 평가한다. logrotate 프로세스가 상시 실행되어 정확히 자정마다 모든 파일을 자르는 것은 아니며 실제 timer 또는 cron 실행 시각이 영향을 준다.
• Rotaterotate 14는 보관 회전본 수이고, 크기 조건과 수동 실행 등 운용 방식이 달라지면 반드시 정확한 14일 보존을 뜻하지 않는다.
• 압축 지연compress는 오래된 회전 파일 압축이고 delaycompress는 가장 최근 회전본의 압축을 다음 주기로 미룬다. writer 또는 reader가 직전 파일을 아직 사용하는 경우 도움이 되지만 copytruncate의 복사·삭제 경쟁을 해결하지 않는다.
• 누락·빈 파일missingok와 notifempty는 각각 없는 파일과 빈 파일의 처리 정책이다.
• Create 무효copytruncate와 create를 함께 지정하면 create는 효과가 없다. 원래 파일을 지우고 다시 만드는 방식이 아니기 때문이다.
• 설정 범위다음 설정은 copytruncate를 선택한 학습 예다. Writer가 reopen을 지원하면 rename 방식과 비교해야 하며 copytruncate는 무손실을 보장하지 않는다.

/var/log/snort/alert_fast.txt {
 daily
 rotate 14
 missingok
 notifempty
 compress
 delaycompress
 dateext
 copytruncate
}

수업 MVP의 선택을 재구성했다. writer가 reopen을 지원한다면 rename 방식과 수집기의 전환 처리를 먼저 비교한다.

08재시작 복구와 전달 확인: 읽음과 적재됨의 차이

• 읽음과 적재수집기가 읽은 즉시 offset을 영속 저장한 뒤 전송 전에 죽으면 재시작 때 이미 읽은 것으로 판단하여 미전송 기록을 건너뛸 수 있다. 반대로 전송 후 확인 응답을 받기 전에 죽으면 재전송하여 중복이 생길 수 있다.
• Checkpoint단순한 offset 파일 하나로 손실과 중복을 모두 없애지는 못한다.
• 재전송at-least-once 전송은 확인되지 않은 기록을 다시 보내 손실 가능성을 줄이고 수신 측에서 중복을 처리하는 접근이다. 이벤트 ID에는 소스 식별자, 파일 세대, 위치 등 재시작 후에도 일관된 기준이 필요하며 내용 해시만 쓰면 실제로 반복 발생한 동일 내용 사건을 잘못 합칠 수 있다.
• 중복 제어중앙 서버가 응답할 시점도 정해야 한다. 메모리에 받았을 때와 영속 저장이 끝났을 때는 보장 범위가 다르다.
• 메모리 큐DataBuffer가 메모리만 사용하면 프로세스 장애 때 소실될 수 있으므로 디스크 큐와 보관량·역압력·버림 정책을 설계한다.

12검증 시나리오와 대체 수집 경로

• 순번 시험격리된 실습에서 순번이 있는 시험 로그를 연속 생성하고 회전 전후 원본·보관본·수집 결과의 순번을 비교한다. 정상 회전뿐 아니라 회전 도중 writer 계속 쓰기, 수집기 재시작, 긴 부분 줄, 연속 회전, 중앙 서버 중단을 시험해야 어디에서 누락·중복되는지 알 수 있다.
• 다른 전송 경로Unix 소켓이나 TCP·RELP 전송으로 파일 회전 의존성을 줄일 수 있지만 소켓 버퍼 초과, 재연결, 큐 영속성과 수신 확인 문제는 남는다. 메시지 브로커는 확인 응답·보존·재처리를 제공할 수 있으나 운용 복잡성과 저장 비용도 늘어난다.
• 무손실의 조건“파일 대신 네트워크면 무손실”이라는 결론 대신 각 경계의 실패 동작을 비교한다.
• 보관과 지연보관 만료는 수집 완료 확인보다 빨리 일어나지 않아야 한다. 회전 파일을 압축하거나 지우는 정책과 지연된 수집기의 복구 가능 시간을 함께 정하고, 경보 수집 지연과 마지막 성공 위치를 운영 지표로 남긴다.