filebeat 8.7 버전의 filestream input 타입으로 로그 파일을 수집하는 환경에서 로그 파일을 재수집하는 이슈가 발생했다.
로그파일은 일자별로 rotate되고 있는 상황이었다.
특정 일자의 로그 파일을 수집하다가 처음부터 다시 읽는 현상 간헐적으로 발생했고 어떤 파일만 재수집했는지 registry를 분석했다.
두가지 상황에서 재수집했다.
1. 파일비트 재시작 할 때
2. 특정 파일을 수집하는 도중에 처음부터 수집하는 경우
분석 결과, 1번의 경우에 재시작하면서 registry에 저장된 inode에 해당된 파일을 읽으려고 시도
-> 저장된 offset이 파일의 바이트 크기보다 커서 offset에 해당하는 내용이 없음
-> 처음부터 수집, 파일비트 로그는 다음과 같이 찍힘 File was truncated. Reading file from offset 0.
offset이 파일의 바이트보다 큰 이유를 생각해보면, 몇 달 전 날짜의 로그 파일의 offset이 삭제되지 않았고 예전 로그 파일의 inode가 재할당 되면서 예전 파일의 offset을 읽어서 꼬인 것이다.
2번의 경우도 마찬가지로 inode가 재사용되어 offset이 꼬인 것으로 보인다.
찾아보니 registry에서 remove를 정상적으로 수행하지 않는 이슈가 beats 공식 GitHub에 올라와있어서, 최신 버전의 파일비트(8.13.2)로 테스트했다.
파일이 삭제되면 registry에서 삭제되는 옵션인 clean_removed 가 정상적으로 동작하는지 확인하고 버전업했다.
(이슈 링크)
최근까지 이슈가 계속 올라오는 것으로 보아 8버전의 filestream input 타입이 아직 안정적이지는 않은 것 같다. 사내에서는 모니터링 용도로만 사용되어서 큰 문제가 없지만 중요한 로직이나 프로세스에 사용될 때는 7버전의 log type을 사용하거나 aws에서 완전히 관리되는 kinesis와 같은 서비스를 사용하는게 좋을 듯하다.
'ELK' 카테고리의 다른 글
[Filebeat] 파일 수집과 registry (1) | 2024.07.14 |
---|---|
Kibana circuit_breaking_exception (1) | 2024.07.10 |