Part 1 : logrotate - 로그 파일을 자동으로 관리하자 

logrotate란?

리눅스 시스템의 로그 파일은 시간이 지남에 따라 용량이 커지고, 관리가 어려워질 수 있습니다.

logrotate는 이러한 로그 파일을 주기적으로 순환(rotate) 하여 압축하거나 삭제함으로써 디스크 용량을 효율적으로 관리해 주는 도구입니다.

 

동작 방식 요약

● 주기적으로 로그 파일을 새로운 파일로 교체하고,

● 이전 로그는 압축(.gz)하거나 일정 개수 이상이면 삭제합니다.

● 설정 파일을 기반으로 동작합니다.

 

설정 파일 경로

/etc/logrotate.conf
/etc/logrotate.d/

 

예시 설정 (/etc/logrotate.d/nginx)

nginx 로그파일의 logrotate 설정 파일

상세 옵션 설명

항목 설명
daily 로그를 매일 회전합니다.
missingok 로그 파일이 없어도 에러 없이 넘어갑니다.
rotate 14 로그 파일을 최대 14개 보관하고, 그 이상은 삭제됩니다.
compress 회전된 오래된 로그 파일을 gzip으로 압축합니다 (예: .log.1.gz)
delaycompress 바로 압축하지 않고 다음 회전 때 압축합니다.
notifempty 로그 파일이 비어있다면 회전하지 않습니다.
create 0640 www-data adm 새 로그 파일을 생성할 때 권한 0640, 소유자 www-data, 그룹 adm 으로 설정합니다.
sharedscripts 여러 로그 파일에 대해 하나의 prerotate 및 postrotate 스크립트만 실행되도록 합니다.

 

prerotate 블록

prerotate
    if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
        run-parts /etc/logrotate.d/httpd-prerotate; \
    fi \
endscript

● 로그 회전 전에 실행되는 스크립트입니다.

● /etc/logrotate.d/httpd-prerotate 디렉터리가 있다면, 그 안에 있는 스크립트를 run-parts로 실행합니다.

● 일반적으로 Apache용 설정인데, 환경에 따라 공통 처리 스크립트를 두는 용도로 쓰일 수 있습니다.

 

postrotate 블록

postrotate
    invoke-rc.d nginx rotate >/dev/null 2>&1
endscript

● 로그 회전 후에 실행되는 명령입니다.

● invoke-rc.d nginx rotate는 nginx 프로세스에 로그 파일을 다시 열도록 명령합니다. 그렇지 않으면 nginx는 여전히 삭제된 이전 로그에 계속 로그를 쓰게 됩니다.

● 출력은 모두 숨김 처리 (>/dev/null 2>&1).

 

요약

● nginx 로그 파일을 매일 회전하고, 

14개까지 백업을 보관하며, 

압축 및 권한 설정, 비어있을 경우 생략 등을 자동 처리합니다.

● 회전 전과 후에 스크립트를 실행하여 nginx가 새 로그를 제대로 인식하도록 돕습니다.

 

수동 테스트

sudo logrotate -d /etc/logrotate.conf	# 디버그 모드 (동작 예측)	
sudo logrotate -f /etc/logrotate.conf	# 강제적 실행

 

Part 2 : journalctl과의 차이점

journalctl이란?

journalctl은 systemd에서 제공하는 이진(binary) 형식의 로그 시스템입니다.

로그가 /var/log/*.log 처럼 파일에 저장되는 대신, 바이너리 형식으로 /var/log/journal 디렉터리에 저장되며 다양한 필터링 기능을 제공합니다.

 

주요 차이점 비교

항목 logrotate journalctl
로그 저장 방식 텍스트 파일  바이너리 형식 (systemd-journald)
저장 위치 /var/log/*.log /var/log/journal/
관리 방식  주기적 순환, 압축, 삭제 journald.conf 로 보존 기간/크기 설정
필터링 기능  grep, awk 등 수동 처리 journalctl에서 강력한 필터링 지원
대상 시스템 SysVinit, 전통적인 서비스 구조 systemd 기반 시스템
예시 명령어 tail -f /var/log/syslog journalctl -u nginx.service

 

journal 로그 보존 설정 (/etc/systemd/journald.conf)

/etc/systemd/journald.conf

저장 관련 옵션

항목 설명
#Storage-auto 로그 저장 방식:
- auto: /var/log/journal 디렉토리 있으면 디스크, 없으면 메모리 저장
- persistent : 항상 디스크에 저장
- volatile : 항상 메모리에 저장
- none : 저장하지 않음
#Compress=yes 오래된 로그 파일을 압축하여 저장할지 여부 (yes/no)
#Seal=yes 로그 파일에 "무결설 서명(seal)"을 할지 여부 (보안 강화)
#SplitMode=uid 사용자 UID별로 로그를 분할할지 설정:
- uid : 사용자별로 분할
- none : 분할 안 함
#SyncIntervalSec=5m 로그를 디스크에 "동기화(쓰기 flush)" 하는 주기
#RateLimitIntervalSec=30s 로그 속도 제한 간격 : 30초 동안
#RateLimitBurst=10000 로그 최대 burst 수 : 설정한 시간 내 최대 10.000건까지만 허용

 

디스크 사용량 제어

항목 설명
#SystemMaxUse= /var/log/journal 전체에서 사용 가능한 최대 용량
#SystemKeepFree= 로그 저장 후 남겨야 할 최소 디스크 공간
#SystemMaxFileSize= 하나의 로그 파일의 최대 크기
#SystemMaxFiles=100 시스템 로그 파일 최대 개수
#RuntimeMaxUse= /run/log/journal (RAM)에서 사용 가능한 최대 용량
#RuntimeKeepFree= 메모리 로그 저장 후 남겨야 할 최소 메모리
#RuntimeMaxFileSize= 메모리 로그 파일의 최대 크기
#RuntimeMaxFiles=100 메모리 로그 파일 최대 개수

 

보존 기간 관련 옵션

항목 설명
#MaxRetentionSec= 최대 보관 기간 설정 (초 단위)
#MaxFileSec=1month 하나의 로그 파일이 유지될 최대 기간 (예: 1개월)

 

외부 로그 전달 설정

항목 설명
#ForwartToSyslog=yes 로그를 /dev/log로 포워딩하여 rsyslog 등에서 수집 가능
#ForwardToKMsg=no 커널 메시지 버퍼(/dev/kmsg)로 로그 포워딩 여부
#ForwardToConsole=no 시스템 콘솔(/dev/console)에 로그를 출력할지 여부
#ForwardToWall=yes wall 명령어를 통해 사용자에게 브로드캐스트할지 여부

 

콘솔 및 출력 레벨 설정

항목 설명
#TTYPath=/dev/console 콘솔 장치 경로
#MaxLevelStore=debug 저장할 최대 로그 레벨 (가장 자세한 레벨까지 저장 가능)
#MaxLevelSyslog=debug syslog로 포워딩할 최대 로그 레벨
#MaxLevelKMsg=notice 커널 메시지로 보낼 최대 로그 레벨
#MaxLevelConsole=info 콘솔에 출력할 최대 로그 레벨
#MaxLevelWall=emerg wall로 브로트캐스트할 최대 로그 레벨

 

기타 옵션

항목 설명
#LineMax=48K 한 줄의 최대 길이 (기본값은 48KB)
#ReadKMsg=yes 커널 메시지를 읽을지 여부 (/dev/kmsg에서 읽기)

 

예시 명령어 비교

목적 logrotate journalctl
최근 로그 보기 tail -f /var/log/syslog journalctl -f
서비스 로그 보기 cat /var/log/nginx/error.log journalctl -u nginx
날짜별 필터링  grep 'May' /var/log/syslog journalctl --since "2024-05-01"
부팅 이후 로그 (불가) journalctl -b

 

마무리

logrotate텍스트 기반 로그 파일을 관리하는 전통적인 방식입니다.

● journalctl은 systemd가 도입되면서 함께 등장한 현대적인 로그 시스템입니다.

● 이 둘은 공존 가능하며, 실제로 많은 시스템이 둘을 함게 사용하고 있습니다.

+ Recent posts