회사의 개발 서버에 올려두고 테스트 중인 API 서버가 통신을 잘하고 있는지 확인하기 위해서 log를 확인할 때가 있다. 또 응답 결과에 대해 실제 데이터를 개별적으로 확인할 일이 있을 때도 있다. 데이터가 20초~60초 단위로 쌓이기 때문에 하루치 log만 해도 꽤 많은 양이 쌓이고 있었다. 그런데, 문제는 log가 파일 하나에 쌓이고 있었다는 점이다. 여기에 몇 가지 pain point가 있었다.
-
특정 날짜 또는 시각의 데이터를 확인하기 위해서는 직접 해당 위치로 가서 보거나 문자열 검색을 통해 확인해야만 했다.
-
log파일의 크기가 점점 커졌다. 사실 테스트 중인 API 서버는 실시간성 정보를 전달하는 역할을 하고 있으므로 시간이 꽤 지난 후에는 그 의미를 잃어버리기 때문에 굳이 과거 log데이터를 저장해놓을 필요는 없다고 생각했다.(1달 이내의 로그 정도는 필요할 수도 있음)
이런 문제를 해결하기 위해 로그를 날짜별로 다른 파일로 만들어 관리하기로 하고 logrotate를 사용했다.
Logrotate란?
linux에서 log 파일을 관리하기 위한 기능
Logrotate 설정
/etc/logrotate.d 아래에 개별 프로세스에 대한 logrotate 설정 파일을 아래와 같이 작성하여 생성한다.
/opt/wd/log/*.log
{
daily
rotate 50
missingok
notifempty
nocompress
dateext
dateyesterday
create 644 root root
sharedscripts
postrotate
killall -s SIGUSR1 gunicorn
endscript
}
log디렉토리 하위에 .log 확장자를 가지는 모든 파일에 대한 설정
- daily : 로테이트 주기(weekly, monthly, yearly)
- rotate : 유지할 백업 파일 개수
- missingok : 로그 파일이 없더라도 오류를 발생시키지 않음
- notifempty : 파일의 내용이 없으면 새로운 로그 파일을 생성하지 않음
- nocompress : 로그 파일을 압축하지 않음
- dateext : 로그 파일 확장자에 날짜를 표기
- dateyesterday : 로그 파일 생성일 기준 전일 날짜로 확장자에 표기(dateext와 함께 사용)
- create 644 root root : 로그 파일에 대한 권한 설정
- sharedscripts : postrotate 스크립트를 한 번만 실행
- postrotate ~ : rotate작업후에 실행할 명령 설정
copytruncate 옵션 사용하지 않는 이유
copytruncate : 기존 파일을 백업해서 다른 파일로 복사하고 기존 파일 내용은 삭제.
이 옵션을 사용하지 않으면 현재 사용중인 로그 파일을 다른 이름으로 바꿔 move하고 새로운 로그 파일을 생성.
but, 로그파일의 크기가 클 경우(GB단위), copy작업때문에 시스템에 I/O로드가 증가하여 응답속도가 느려지거나 일부 로그가 유실될 가능성이 생긴다.
따라서, signal을 이용하여 파일을 reopen하여 로그파일을 다시 쓸 수 있도록 한다.
gunicorn의 경우 USR1 signal이 reopen에 해당하는 시그널이므로 postrotate 뒤에 해당 시그널을 보내 파일을 reopen하도록 설정했다.
'Development > Linux' 카테고리의 다른 글
[Linux]Ubuntu apt-get install 에러 해결 (0) | 2020.08.12 |
---|---|
[Linux] Mac에서 Virtual Box로 Ubuntu 환경 설치 & SSH접속 설정 (0) | 2020.08.09 |
[Linux]chmod에 대하여 (0) | 2019.06.21 |