logrotate가있는 rsyslog : rsyslog를 다시로드하고 copytruncate

기본 rsyslog 및 logrotate 유틸리티를 사용하여 Ubuntu 14에서 작업하고 있습니다.

기본 rsyslog logrotate /etc/logrotate.d/rsyslog구성에서 다음을 볼 수 있습니다.

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

내가 이해 한 바에 따르면 모든 로그 회전 시나리오에서 copytruncate를 사용하는 것이 좋습니다. 현재 로그는 이동하지 않지만 오히려 로그를 자르므로 열린 파일 처리기가있는 프로세스는 계속 쓸 수 있습니다.

그렇다면 rsyslog reload 기능을 대신 사용하여 기본 구성을 어떻게 구할 수 있습니까?

질문에 대답하려면 먼저 다시로드 및 복사 잘림의 다른 트레이드 오프를 이해해야합니다.

• reload : 이전 로그 파일의 이름이 바뀌고 해당 로그에 쓰는 프로세스에 (UNIX 신호를 통해) 통지되어 로그 파일을 다시 만듭니다. 이것은 가장 빠르고 낮은 오버 헤드 방법입니다. 이름 바꾸기 / 이동 작업은 매우 빠르며 일정한 실행 시간이 있습니다. 또한 이는 거의 원 자성 작업이므로 이동 / 재로드 중에 로그 항목이 거의 손실되지 않습니다. 반면, 로그 파일을 다시로드하고 다시 열 수있는 프로세스 가 필요 합니다. Rsyslog는 이러한 프로세스이므로 기본 logrotate 구성은 reload 메소드를 사용합니다. rsyslog 업스트림에서는 rsyslog와 함께이 모드를 사용하는 것이 좋습니다.
• copytruncate : 이전 로그 파일이 아카이브 파일로 복사 된 다음 이전 로그 라인을 "삭제"하기 위해 잘립니다. 자르기 작업이 매우 빠르지 만 복사 시간이 길어질 수 있습니다 (로그 파일의 크기에 따라 다름). 또한 복사 작업 (느리게 진행될 수 있음)과 잘라 내기 사이의 시간 동안 일부 로그 항목이 손실 될 수 있습니다. 이러한 이유로 copytruncate는 기본적으로 로그 파일을 다시로드하고 다시 생성 할 수있는 서비스에 사용되지 않습니다. 반면에 서버가 로그 파일을 다시로드 / 재 작성할 수 없는 경우 copytruncate가 가장 안전한 방법입니다. 즉, 서비스 수준 지원이 필요하지 않습니다. rsyslog 업스트림 프로젝트는이 모드를 사용하지 않는 것이 좋습니다.

rsyslog 작성자로서, copytruncate는 실제로 매우, 매우 나쁜 선택입니다. 본질적으로 매우 거칠고 사용하면 거의 로그 데이터가 손실된다는 보장이됩니다. 파일이 자주 기록 될수록 더 많이 잃게됩니다. 그리고 이것은 마지막 라인의 일부일뿐만 아니라 회전이 발생할 때 시스템의 정확한 타이밍과 상태에 따라 수백 개의 라인이 될 수 있습니다.

파일이 이동되고 새 inode (파일)가 작성되면 rsyslog는 이전 파일을 추적하고 처리를 완료합니다. 따라서이 경우 손실이 없습니다. 보장됨 (파일 시스템을 마운트 해제 한 경우 제외) ...

"reopenOnTruncate"에서 : 개인적으로 reopenOnTruncate가 다른 측면에서, 특히 NFS와 같은 경우에 비싸다는 것을 알았습니다. 얼마 전에 나는 그 기능을 완전히 제거했지만 나중에 비슷한 기능을 다시 병합하도록 설득했습니다. 사람들이 매우 많이로드 된 시스템에서 문제를 겪고 있다는 것을 알기 때문에 아마도 "실험적인"상태를 유지하게 될 것입니다. "copytruncate"는 로그 파일 작업에 적합한 모드가 아닙니다.

현재 imfile 리팩토링 작업을하고 있습니다 (ETA 8.34 또는 8.35). 리팩토링 된 버전은 아마도 API 경쟁으로 인한 우발적 인 재전송을 방지 할 수있을뿐 아니라 개념 상 불가능하기 때문에 데이터 손실을 막을 수 없습니다.

이것은 프로세스가 로그를 작성하는 방법에 전적으로 달려 있습니다.
copytruncate로그 메시지가 파일에 추가하는 경우에만 작동합니다 (예 whatever >> logfile.
그리고되지는 예를 들어, 출력 (리디렉션되는 경우 whatever > logfile).

버전 8.16부터 rsyslog에는 reopenOnTruncatecopytruncte 문제를 처리하는 imfile 옵션 이 있습니다.

특히 rsyslog의 경우에는 그대로 두는 것이 더 합리적입니다.

기본 이유는 rsyslog에 출력 핸들을 사용할 수없는 경우 사용할 수있는 내부 큐가 있기 때문입니다.

다시로드하면 a) rsyslog가 자체 로그 파일을 다시 만들고 b) 큐 이벤트가 작성 될 때 파일로 플러시됩니다.

copytruncate는 아무런 해를 끼치 지 않을 수도 있지만 (부분적으로 작성된 줄이 잘리는 것에 대해 걱정할지라도) 복사 / 삭제 / 다시로드는 무결성 관점에서 '안전합니다'라고 생각하는 경향이 있습니다.

@ faker 에서 언급했듯이 rsyslog는 파일을 사용할 수 없게되는 상황을 처리 할 수 ​​있으므로 copytruncate를 사용해야하는 강력한 이유가 없습니다.

@ SelivanovPavel 에서 언급했듯이 rsyslog는 실제로 복사 잘림을 올바르게 처리하기 위해 특정 구성이 필요합니다.

따라서 reload접근 방식을 사용하는 것이 기본 구성과의 편차가 적기 때문에 유지해야합니다.