로그가 디스크를 포화시키기 전에 로그 회전을 테스트합니다

Julien Macé Published on 7 9월 2026 at 7 h 42 min 3 min read

Une règle Logrotate doit être simulée avant d’archiver le journal d’un service.

조용히 커지는 애플리케이션 로그는 서비스가 중단되기 전에 /var를 채울 수 있습니다. Logrotate 규칙이 설정된 것처럼 보일 때, 가장 좋은 출발점은 그 구성 파일을 읽고 실험 파일에 그 효과를 시뮬레이션하는 것입니다.

실제 로드된 규칙을 확인하고 logrotate -d를 실행한 다음, 자체 상태 파일을 가지고 테스트 로그에서 회전을 강제합니다. 프로덕션 로그는 절차 전반에 걸쳐 intact 상태로 유지됩니다.

Linux 서버와 로그, 로그 아카이브 및 회전이 설명된 그림 — Logrotate 규칙은 서비스 로그를 아카이브하기 전에 시뮬레이션되어야 합니다.

Logrotate를 실행하기 전에 구성 읽기

Debian 및 Ubuntu에서는 기본 구성 파일이 종종 /etc/logrotate.conf에 있으며 /etc/logrotate.d/에 있는 규칙을 로드합니다. Rocky Linux도 대부분의 설치에서 이 구성을 사용합니다. 이 폴더에 있는 규칙만으로는 충분하지 않습니다: 로그 경로, 권한 및 상속된 지침이 일관성을 유지해야 합니다.

sudo sed -n '1,220p' /etc/logrotate.conf
sudo ls -l /etc/logrotate.d/
sudo grep -R --line-number '/var/log/mon-app' /etc/logrotate.conf /etc/logrotate.d 2>/dev/null

/var/log/mon-app를 관련 로그의 경로로 바꾸십시오. 결과는 읽을 수 있는 하나의 규칙을 가리켜야 합니다. 같은 파일을 대상으로 하는 두 개의 규칙이 있다면, 강제 회전 이전에 구성을 수정해야 합니다.

로그 파일이 존재해야 하며, 그렇지 않으면 규칙에 missingok가 포함되어야 합니다.
su 사용자 그룹에 의해 지정된 계정은 디렉터리를 읽을 수 있어야 하고, create가 사용될 경우 새 로그를 생성할 수 있어야 합니다.
olddir 지침은 아카이브를 동일한 파일 시스템에 배치합니다. 규칙이 적절한 복사 방법을 사용하는 경우는 제외입니다.
daily 또는 weekly 빈도는 매번 시작할 때 회전을 발생시키지 않습니다. 크기와 상태 파일도 결정에 참여합니다.

이 점검 중 로그를 추적하려면 리눅스에서의 tail -F가 파일을 교체한 후 tail -f보다 더 적합합니다. tail -F는 Logrotate가 새 로그를 생성할 때 경로를 다시 엽니다.

실험 로그 생성하기

활성 서비스에 영향을 주는 규칙을 강제로 적용하여 그 동작을 확인하지 마십시오. 저는 이 테스트를 위해 /var/tmp를 선택하겠습니다: 이 파일은 애플리케이션 로그와는 분리되어 있으며 검증 후 해당 디렉터리를 삭제할 수 있습니다.

sudo install -d -m 0755 /var/tmp/logrotate-lab
sudo sh -c 'printf "%sn" "테스트 라인" > /var/tmp/logrotate-lab/application.log'
sudo tee /var/tmp/logrotate-lab.conf >/dev/null <<'EOF'
/var/tmp/logrotate-lab/application.log {
    size 1
    rotate 2
    compress
    missingok
    notifempty
    create 0640 root root
}
EOF

size 1 지침은 매우 짧은 파일로 테스트를 재현 가능하도록 만듭니다. rotate 2는 최대 두 개의 아카이브를 유지합니다. 이후 사용될 상태 파일은 /var/lib/logrotate/status와 구분되므로 이 실험은 시스템의 이력을 수정하지 않습니다.

회전 시뮬레이션 및 결과 읽기

-d 모드는 로그를 수정하거나 상태 파일을 기록하지 않고 Logrotate의 결정을 표시합니다. 이는 각 규칙 수정 후 실행할 명령입니다.

sudo logrotate -d -s /var/tmp/logrotate-lab/status /var/tmp/logrotate-lab.conf

출력에서 application.log 파일을 보고 크기 기준 회전 결정을 확인해야 합니다. 권한, 구문 또는 경로의 오류는 데이터에 영향을 주지 않고 여기 나타납니다. logrotate -d는 아카이브가 생성되었음을 증명하지 않으며, 이 모드는 어떤 기록도 하지 않습니다.

깨끗한 시뮬레이션 후에, 오직 실험 규칙만을 -v 플래그를 사용하여 강제하여 각 작업을 표시하십시오.

sudo logrotate -vf -s /var/tmp/logrotate-lab/status /var/tmp/logrotate-lab.conf
sudo ls -lh /var/tmp/logrotate-lab/
sudo stat -c '%n %U:%G %a %s 바이트' /var/tmp/logrotate-lab/application.log

명령은 새 application.log를 권한 0640으로 빈 상태로 남기고, .1.gz와 같은 압축된 아카이브를 남겨야 합니다. 새 파일이 예상되는 소유자가 아닐 경우 create와 su를 다시 확인하고 서비스 규칙을 적용하십시오.

강제하지 않고 서비스 규칙 테스트하기

실험이 성공적이면 실제 규칙의 디버그 모드를 유지하십시오. 특정 규칙을 위해 전체 디렉터리를 분석하지 않도록 특정 명령을 사용하면 됩니다. 이는 정상적인 회전에 사용된 상태 파일을 보여줍니다.

sudo logrotate -d -v /etc/logrotate.d/mon-app
sudo journalctl -u logrotate.service -b --no-pager

배포판에 따라 Logrotate는 logrotate.timer, cron 또는 anacron에 의해 트리거됩니다. 서비스 로그는 태스크가 시작되었음을 확인하지만, 디버그 출력을 통해 특정 규칙에 대한 증거가 될 수 있습니다. 리눅스에서의 journalctl 가 현재 시작을 다시 읽는 데 도움이 되며, 유닛이 오류를 보고하는 경우 유용합니다.

신속한 데모를 위해 프로덕션 로그에 -f를 사용하지 마십시오. 조기 회전은 수집기를 망가뜨리거나 애플리케이션이 기대하는 파일을 이동시키거나 수사에 유용한 이력을 삭제할 수 있습니다. 테스트 후에는 sudo rm -rf /var/tmp/logrotate-lab /var/tmp/logrotate-lab.conf로 실험을 정리하십시오.

매뉴얼 페이지 logrotate(8)는 사용 가능한 지침과 그 우선 순위를 설명합니다. 프로덕션에서 회전을 변경하기 전에, 제한된 규칙, 식별 가능한 상태 파일 및 읽을 수 있는 시뮬레이션을 유지하십시오.

Julien Macé