DevOps

로그 로테이트(Logrotate)

kyoulho 2024. 11. 12. 19:04

로그 로테이트(Logrotate)는 리눅스 시스템에서 로그 파일을 자동으로 관리해 주는 유틸리티입니다. 서버에서 생성되는 다양한 로그 파일을 주기적으로 압축, 삭제, 또는 백업하여 저장 공간을 절약하고 관리 효율성을 높여줍니다. 대부분의 리눅스 시스템에 기본적으로 설치되어 있으며, cron 작업으로 자동 실행되어 관리자의 개입 없이 로그 파일을 유지보수할 수 있습니다.

로그 로테이트의 주요 기능

  • 로그 파일 주기 관리: 설정에 따라 매일, 매주, 매달 등의 주기로 로그 파일을 새로 생성합니다.
  • 백업 및 압축: 오래된 로그 파일을 gzip 등으로 압축해 저장 공간을 절약하고, 지정한 개수만큼만 보관합니다.
  • 자동 삭제: 설정된 개수를 초과하는 오래된 로그 파일은 자동으로 삭제해 불필요한 로그 파일이 누적되지 않도록 합니다.
  • 유연한 설정 옵션: 특정 로그 파일이나 서비스별로 개별 설정을 지정해, 다양한 로그 파일의 관리 요구 사항을 충족시킵니다.

 

로그 로테이트 설정 방법

1. 전역 설정

전역 설정은 /etc/logrotate.conf 파일에서 정의되며, 시스템 전체에 공통으로 적용되는 기본 설정을 포함합니다. 전역 설정을 통해 로그 파일의 기본 동작을 정의하고, 필요한 경우 개별 설정에서 이를 덮어쓸 수 있습니다.

주요 옵션 설명:

  • daily, weekly, monthly: 로그 로테이션 주기를 설정합니다.
  • rotate <number>: 보관할 로그 파일의 개수를 지정합니다. 예를 들어, rotate 4로 설정하면 최근 4개의 로그만 보관합니다.
  • compress: 로테이션된 로그 파일을 gzip으로 압축합니다.
  • delaycompress: 직전 회차의 로그 파일은 압축하지 않고, 그 다음 회차에서 압축합니다.
  • missingok: 로그 파일이 없어도 오류를 발생시키지 않고 넘어갑니다.
  • notifempty: 로그 파일이 비어 있으면 로테이션하지 않습니다.
  • create <mode> <owner> <group>: 새 로그 파일의 권한, 소유자, 그룹을 설정합니다.

전역 설정 예시:

# /etc/logrotate.conf
weekly                  # 주간 로테이션
rotate 4                # 최근 4개의 백업 로그 파일 보관
create                  # 새 로그 파일을 생성
compress                # 로그 파일을 gzip으로 압축
include /etc/logrotate.d  # 개별 설정 디렉토리 포함

 

2. 개별 설정

개별 설정은 /etc/logrotate.d/ 디렉토리 내에 위치한 파일들에서 관리되며, 특정 서비스나 로그 파일에 대해 상세한 설정을 적용할 수 있습니다. 전역 설정에서 정의한 기본 동작을 덮어쓸 수 있으며, 로테이션 후 특정 명령을 실행하는 등의 서비스별로 고유한 설정을 할 수 있습니다.

개별 설정 항목:

  • postrotate/endscript: 로테이션 후 특정 명령을 실행할 수 있습니다. 예를 들어, Nginx나 Apache 서비스가 새 로그 파일을 열도록 명령할 때 사용됩니다.
  • prerotate/endscript: 로테이션 전에 특정 명령을 실행할 수 있습니다.
  • /path/to/logfile: 로테이션할 로그 파일의 경로를 지정하며, 여러 파일을 와일드카드로 지정할 수도 있습니다.

개별 설정 예시:

# /etc/logrotate.d/nginx
/var/log/nginx/*.log {
    daily                 # 매일 로테이션
    dateext               # 로테이션 된 로그 파일 이름에 날짜를 붙임
    dateformat -%Y%m%d    # 날짜 확장자를 붙일 때 사용할 포맷 지정
    rotate 7              # 최근 7개의 로그 보관
    compress              # 회전된 로그 파일을 gzip 등으로 압축
    delaycompress         # 직전 파일은 압축하지 않음
    missingok             # 파일이 없을 때 오류 발생 안 함
    notifempty            # 빈 파일은 로테이션 안 함
    create 0640 kyoulho kyoulho  # 새 로그 파일의 권한, 소유자 설정
    sharedscripts         # 여러 개의 로그 파일이 한 번에 처리될 때, postrotate 등의 스크립트를 한 번만 실행
    postrotate            # 로그 로테이션 후 실행할 스크립트 블록
        systemctl reload nginx > /dev/null
    endscript
    su root root          # 로그 로테이션을 수행하는 사용자와 그룹을 지정
}

이 설정은 Nginx 로그 파일을 매일 로테이션하며, 최근 7개의 백업을 보관하고 필요시 Nginx를 재시작하여 새 로그 파일을 열도록 구성한 예입니다.

로그 로테이트 실행 시 발생할 수 있는 권한 문제와 해결 방법

1. 파일 접근 권한 문제

  • 문제: 로그 파일에 대한 읽기/쓰기 권한이 없을 경우 로테이션 작업이 실패합니다. 특히 /var/log/ 디렉토리의 로그 파일들은 루트 권한이 필요합니다.
  • 해결 방법:
    • 루트 사용자로 실행: 로그 로테이트를 sudo 명령을 통해 루트 권한으로 실행하거나, cron 작업에서 루트 사용자로 자동 실행되도록 설정합니다.
    • 특정 파일 권한 변경: 로테이션이 필요한 특정 파일의 읽기/쓰기 권한을 필요한 사용자에게 부여합니다. 예를 들어, chmod 640 /var/log/mylog.log 명령으로 파일 권한을 수정할 수 있습니다.
    • 파일 소유자 변경: 로그 파일의 소유자를 로그 로테이트를 실행하는 사용자로 설정합니다(chown 명령 사용).

2. 디렉토리 접근 권한 문제

  • 문제: 로그 파일이 위치한 디렉터리에 쓰기 권한이 없으면 로그 파일을 생성하거나 이동할 수 없습니다.
  • 해결 방법:
    • 디렉토리 권한 변경: 로그 파일을 생성할 디렉터리에 쓰기 권한이 필요한 사용자에게 부여합니다.
    • 소유자 변경: 해당 디렉토리의 소유자 권한을 로그 로테이트 작업을 수행할 사용자로 설정합니다.

3. 서비스 재시작 권한 문제

  • 문제: 로테이션 후 postrotate 스크립트에서 서비스(Nginx, Apache 등)를 재시작하려면 해당 서비스에 대한 접근 권한이 필요합니다. 일반 사용자는 systemctl 명령을 사용할 수 없어 명령이 거부될 수 있습니다.
  • 해결 방법:
    • sudo 설정: /etc/sudoers 파일에 특정 사용자에게 systemctl reload 명령을 사용할 수 있는 권한을 추가합니다. 예를 들어, www-data 사용자가 nginx를 다시 로드할 수 있게 하려면 /etc/sudoers에 다음을 추가합니다:
      www-data ALL=(ALL) NOPASSWD: /bin/systemctl reload nginx
    • 루트 사용자로 실행: postrotate 스크립트가 루트 권한으로 실행되도록 하여 서비스 명령에 접근할 수 있게 합니다.

4. 파일 소유자 및 그룹 문제

  • 문제: create 옵션으로 새 로그 파일을 생성할 때, 지정된 소유자와 그룹으로 파일을 생성할 권한이 없으면 로그 파일 생성에 실패할 수 있습니다.
  • 해결 방법:
    • 적절한 소유자/그룹 설정 확인: create 옵션에서 지정한 소유자와 그룹이 올바르게 설정되었는지 확인합니다.
    • 사용자 권한 변경: 로그 로테이트가 실행될 사용자가 새로 생성되는 로그 파일을 소유하도록 create 설정을 수정하거나, 로그 파일의 소유자 권한을 적절하게 수정합니다.
728x90

'DevOps' 카테고리의 다른 글

[MW] Flyway  (0) 2024.08.31
[Git] Merge 전략  (0) 2024.08.25
[Git] Git 워크플로우 비교: GitHub Flow, Gitflow, GitLab Flow  (0) 2024.07.30
RabbitMQ, Apache Kafka, AWS SQS 비교  (0) 2024.01.13
Apache Kafka  (0) 2023.12.30