preview image
허원철의 개발 블로그

Amazon Linux에서 /var/log가 꽉차는 이슈

2021-05-23

개발 초기, 개발서버에서 /var/log에 상당히 많은 데이터가 쌓이면서 골치가 아픈 적이 있다. 리눅스에 대해 많은 지식이 없는 상황에서 다행히 팀원의 도움으로 빨리 해결 방법을 알게 되었지만, 모르는 내용이 있어 이를 블로깅하여 기록해두려 한다.

리눅스에서는 내부에서 발생하는 이벤트에 대한 로그를 관리하는 시스템이 존재한다. 일단 한 놈(?)만 파보고자 회사에서 사용하는 amazon linux2의 로깅 시스템에 대해서 알아보고자 한다.

Amazone Linux2

공식문서는 여기서 확인할 수 있다.

Amazon Linux는 CentOS처럼 RedHat계열의 리눅스이다.

systemd

systemd 이란?

systemd는 일부 리눅스 배포판에서 유닉스 시스템 V나 BSD init 시스템 대신 사용자 공간을 부트스트래핑하고 최종적으로 모든 프로세스들을 관리하는 init 시스템이다.

Amazone Linux2는 systemd를 init 시스템으로 채택하여 사용하고 있다. 여기서 init 시스템이란 컴퓨터 시스템의 부팅 과정 중 최초의 프로세스이다.

systemd 구조

alt systemd-components

위 그림과 같은 구조를 가지고 있다. 이 글에서 모두 언급하기 어렵기도 하고 이슈를 해결하기 위해 봐야했던 부분만 언급해보고자 한다.

systemd 로깅 시스템

systemd-journald is a daemon responsible for event logging, with append-only binary files serving as its logfiles. The system administrator may choose whether to log system events with systemd-journald, syslog-ng or rsyslog. The potential for corruption of the binary format has led to much heated debate

사용하고 있는 로깅 서비스 확인해보기



현재 실행 중인 systemd-journald, rsyslog를 찾아보자!

systemd-journald

rsyslog

fluentd와 흡사한 도구라고 느껴짐


  • 전부 찾아보진 않았지만 Output Module에는 기본 내장 모듈이 존재 (omusrmsg, omfile)

Input Module(imjournal)

  • imjournal으로도 imklog와 동일하게 커널 로그를 읽을 수 있다고 함

logrotate

그런데 /var/log/messages 를 검색해보면 날짜별로 rotate되는 것으로 보인다. 또 이건 어떤 서비스가 이를 처리하는 것 일까?



그것이 바로 logrotate라는 녀석이다. 요약하자면, /etc/cron.daily/logrotate 이 스크립트가 매일 실행되면서 /etc/logrotate.conf/etc/logrotate.d/ 하위에 파일들의 설정으로 rotate가 되는 것인데, 자세한 설명은 이 블로그에 자세히 설명되어 있어 이를 대신한다.

실제로 /etc/logrotate.d/syslog 설정을 확인 해보면 /var/log/messages가 rotate 되는 목록에 포함되어 있는 것을 알 수 있다.

결론

  1. 시스템 이벤트가 발생하면 systemd-journald가 이를 수집
  2. systemd-journald에서 바이너리 형태로 로그 파일을 만듬
  3. rsyslog(input module=imjournal)으로 systemd-journald에서 syslog로 구조화된 로그를 가져옴
  4. /var/log 하위에 rule에 맞는 로그로 출력
  5. /var/log 하위 로그들은 logrotate로 인해 매일 rotate

느낀점

@ /var/log에 굉장히 다양한 로그가 쌓이는 것을 알게되었다. (부팅, 메일, 메시지, … 등등)
@ systemd에 기본적인 로그 시스템만으로도 다양한 로그를 가공 및 처리를 할 수 있다. 그렇기 떄문에 이를 생각하지 않고 별도의 로그를 가공한다고 작업을 추가하면, 이중으로 작업하게 되는 것이라고 판단된다.
@ systemd-journald을 사용하면 /var/log/journal에 바이너리 형태로 로그가 쌓이는데 이게 맞는 것일까? 🤔
journalctl으로도 볼 수 있지만, /var/log/messages에 쌓이는 것만으로도 충분하지 않나라는 생각이 든다. (이것도 이중 작업이지 않나…? 🤔)
@ (java) 무심코 logback의 console appender으로 설정해두고 서버에 반영하면, /var/log/messages에 쌓이는 것을 경험했다. 🤣
@ 현재 서비스의 애플리케이션 로그를 crontab으로 별도의 스크립트를 등록하여 rotate하고 있는데 logrotate으로 처리하면 보다 깔끔한 처리가 되지 않을까 싶다.