작성자를 깨뜨리지 않고 VPN 감시 로그 회전하기

VPN 상태 점검이 일 분마다 한 줄을 덧붙이면 조용히 두 번째 의무가 생깁니다. 그 줄이 디스크를 떠나는 방식을 정하는 일입니다. 터널을 고쳐도 이 의무에는 아무 효과가 없고, 파일 이름을 바꿔도 이전 디스크립터를 쥐고 있는 프로세스는 방향을 바꾸지 않으므로, 먼저 출력 대상 질문에 답하고 작성자가 여는 방식에 맞춰 회전을 설계하십시오.

회전 정책보다 먼저 출력 대상을 고르십시오

출력을 이미 저널로 보내는 systemd 유닛이면 보존을 한 곳에 둡니다. journald는 SystemMaxUse 및 MaxRetentionSec 같은 한도를 적용하므로, 거기에 기록하는 감시자는 추가 작업 없이 한도를 물려받습니다. 그 옆에 무제한 파일을 하나 더 두면 이득 없이 유지 관리가 두 배가 됩니다.

전용 파일은 파서, 감사 내보내기, 안정적인 경로를 기대하는 페이지처럼 다른 무언가가 읽을 때 제자리를 얻습니다. 그 결정이 나면 파일에는 소유자, 모드, 회전 정책이 함께 적혀야 하며, 셋은 한 세트로만 올바릅니다. 누구나 만들 수 있는 경로는 누구나 바꿀 수 있는 경로이므로 디렉터리 권한도 같은 메모에 넣습니다. 이 모든 것을 점검 옆에 적으면 다음 편집은 같은 사실에서 시작됩니다.

작성자에 맞춰 블록을 작성하십시오

호출할 때마다 경로를 열고 한 줄을 덧붙인 뒤 끝나는 작성자에서 시작하십시오. 이 패턴은 프로세스의 협조 없이 회전을 견딥니다. 다음 실행이 그 시점에 그 경로에 있는 파일을 열기 때문이며, 아래 블록은 일주일 분량의 버전을 유지하고 작성자가 필요로 하는 소유자와 모드로 파일을 다시 만듭니다:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

logrotate 설명서는 개수를 보관하는 회전된 버전 수로 정의하며, 이레 기록을 보장하는 것으로 정의하지 않습니다. 또한 daily 키워드는 자체 스케줄러로 행동하는 대신 작업이 실행될 때 평가됩니다. 대부분의 배포판에서는 systemd 타이머나 cron 항목이 이미 그 호출을 소유하므로 두 번째를 추가하기 전에 어느 것이 있는지 확인하십시오. 소유권을 맞추는 것이 보관 수보다 중요합니다. root 전용 모드를 서비스 계정이 쓰는 파일에 복사하면 다음 회전에서 로깅이 멈추고, 실패는 오류가 아니라 몇 시간 뒤의 오래된 타임스탬프로 나타나므로 다른 곳에서 블록을 복사하기 전에 작성자의 사용자를 확인하십시오.

절대 다시 열지 않는 작성자에게는 다른 처방이 필요합니다

열린 디스크립터를 쥐고 있는 장기 실행 프로세스는 이름이 바뀐 inode에 계속 씁니다. 공간은 해제되지 않고 보이는 파일은 성장을 멈추며, inode를 확인할 때까지 고장 난 회전처럼 보입니다. 프로세스에 다시 열기를 가르치거나, 이름 변경 대신 복사와 잘라내기를 하도록 만드십시오.

다시 열기 경로는 소프트웨어가 지원하는 곳에서 더 깔끔하며, 문서화된 신호를 보내거나 문서화된 명령을 실행하고 프로세스가 새 파일을 스스로 열게 하십시오. 대안은 copytruncate으로, 내용을 회전된 이름으로 복사한 뒤 원본을 제자리에서 잘라내므로 디스크립터는 유효하지만 복사와 잘라내기 사이에 들어간 쓰기는 사라집니다.

systemd가 시작하는 유닛에서는 StandardOutput을 저널이나 파일로 향하게 하고 유닛이 수명 주기를 갖게 하십시오. 크기 한도 없이 tee -a을 통해 덧붙이는 셸 루프는 장애 때 파티션을 채우는 구성인데, 실패하는 점검은 건강한 점검보다 훨씬 많이 기록하는 경우가 많기 때문입니다.

타이머를 기다리지 않고 회전을 시험하십시오

디버그 모드는 무슨 일이 일어날지 보고하고 아무것도 건드리지 않아 편집 후 안전한 첫 실행이 됩니다. 만족하면 실제 회전을 강제하고, 다음 로그 줄이 이름이 바뀐 파일이 아니라 새 파일에 들어가는지 확인하십시오:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

출력을 그 순서대로 읽으십시오. 디버그 실행은 파일과 의도한 동작을 지목해야 하며, 강제 실행은 예상한 회전 이름을 만들어야 하고, tail은 작성자가 다시 실행된 뒤 새 항목을 보여야 합니다. df 값이 늘고 보이는 파일이 줄면 위에서 설명한 디스크립터 문제입니다.

버전이 이미 있을 때 보존이 어떻게 행동하는지 보려면 강제 실행을 두 번 반복하십시오. 가장 오래된 파일을 지우는 것이 예상 결과이고, 삭제가 없다면 보통 회전된 이름의 개수나 와일드카드가 logrotate가 만든 것과 맞지 않는다는 뜻입니다.

롤백과 기록을 남기십시오

편집 전에 이전 블록을 저장하고 어느 스케줄러가 실행하는지 적어 두십시오. 파일만 되돌리고 타이머는 되돌리지 않는 롤백은 원래 문제의 절반을 재현합니다. 복원 후 한 번 손으로 회전하고 작성자의 계정이 로그 경로에 쓸 수 있는지 확인하십시오. 서비스가 systemd 아래에서 실행된다면 출력 리디렉션을 바꾼 뒤 유닛을 다시 로드해야 하며, 실행 중인 프로세스는 이전 대상에 계속 쓰기 때문에 유닛이 깨끗이 돌아왔다고 믿지 말고 다음 몇 줄의 로그를 직접 읽으십시오.

모드, 소유자, 보관 수, 예상 디스크 예산을 점검 옆에 기록하십시오. 나중에 점검이 일회성 스크립트에서 데몬으로 바뀌면 회전 정책도 함께 바뀌어야 하며, 그 메모가 다음 사람에게 어떤 가정이 깨졌는지 알려 줍니다.

마지막으로 로그 결정을 복구 결정과 분리해 두십시오. 실패한 점검은 연결 자체의 복구 정책을 따라야 하며 logrotate 안에 숨은 규칙을 따라서는 안 되고, 어떤 로그 구성도 작동하는 터널을 다시 시작하는 이유가 되어서는 안 됩니다.