OpenVPN 로그는 누구의 것인가: 데몬, rsyslog, 아니면 logrotate?

로그 회전은 예측 가능한 방식으로 깨진다. 세 구성 요소가 각자 파일의 주인이라고 믿고, 그 결과 새 파일은 비어 있는 채로 회전된 로그만 계속 커진다. 데몬은 디스크립터를 쥐고, logrotate는 경로 이름을 바꾸며, rsyslog는 전혀 다른 곳에 쓴다. 더미에 규칙을 하나 더 얹기 전에 작성자 하나와 회전자 하나를 고르라. 아래 점검 목록이 그 순서로 움직이는 이유는 이후의 모든 단계가 그것에 달려 있기 때문이다.

누가 파일을 쓰는지 정하라

두 가지 설계가 정당하다. 첫째는 VPN 프로세스가 자체 log 또는 log-append 옵션으로 파일을 직접 쓰는 것이다. 둘째는 시스템 로거로 레코드를 보내고 rsyslog 또는 journald가 어디에 둘지 정하는 것이다.

이것은 층이 아니라 대안이다. 둘 다 켠 호스트는 서로 어긋나는 파일 두 개를 안고, 읽고 있는 쪽이 대개 낡은 쪽이다. 경로를 의식적으로 고른 뒤 다른 쪽 작성자를 제거하라.

무엇이든 바꾸기 전에 unit 파일을 덮어쓸 수 있는 drop-in까지 포함해 서비스의 실효 설정을 읽어라. 편집한 프로필에 있는 지시문이 실행 중인 프로세스가 읽어 들인 것이라는 증거는 아니다. unit을 프로세스 인자와, 그다음 실제로 연 파일과 대조하라.

필터가 좁아지도록 데몬에 이름을 부여하라

syslog 경로에서는 데몬에 별도의 식별자를 주고 그것으로 걸러라. 이 VPN 인스턴스의 프로그램 이름과 일치하는 규칙은 보존 정책이 다른 것에 속한 공유 파일에서 그 레코드를 떼어 낸다.

좁은 규칙은 다음 질문도 답할 수 있게 한다. 이 줄을 만든 서비스는 무엇인가. VPN이라는 단어가 든 모든 것과 일치하는 필터는 두 번째 터널의 트래픽까지 기꺼이 모아 둘 다 흐리게 만든다. unit이 로거에 넘기는 정확한 식별자에 맞춰라.

레코드가 기본 목적지로도 흘러들지 않도록 동작 뒤에 규칙을 닫아라. 두 파일에 겹쳐 나타난 줄은 로깅 버그처럼 보이지만 실체는 빠진 정지다. 그 한 번의 누락이 보존 정책의 디스크 비용도 두 배로 만든다.

디스크립터를 잃지 않고 회전하라

데몬이 파일을 쓰는 경우 logrotate는 경로 이름을 바꾸지만 프로세스는 열린 디스크립터를 그대로 쥔다. 새 레코드는 무언가가 프로세스로 하여금 원래 경로를 다시 열게 할 때까지 이름이 바뀐 파일로 계속 들어간다. 그래서 회전이 성공한 듯 보이면서 새 파일이 비어 있는 일이 생긴다.

해법은 서비스의 문서화된 재적재나 재시작 동작을 일으키는 postrotate 동작이다. 로거에 시그널을 보내는 것은 전혀 다른 동작이며 자기 파일을 쥔 데몬에는 아무 효과가 없다.

다시 열기가 불가능할 때 copytruncate가 대안이다: 파일을 복사한 뒤 그 자리에서 잘라 낸다. 디스크립터는 유효하게 유지되지만 복사와 절단 사이에 쓰인 것은 모두 잃으므로 해결이 아니라 거래다. 부하가 높으면 그 틈이 붙잡으려는 장애 자체를 삼킬 수 있다.

파일마다 둘 중 하나를 고르고 그 선택을 적어 두라. 같은 경로에서 섞으면 나중에 원인을 밝히기 매우 어려운 틈이 생긴다. 한 디렉터리에서 두 패턴을 모두 발견한 독자는 어느 쪽이 정본인지 판단할 수 없다.

보존은 사고 창에서 정하라

보존, 압축, 최대 크기는 실제로 얼마나 거슬러 조사하는지에서 나와야 한다. 압축과 크기 상한을 둔 칠 일 창은 많은 배포에 합리적 출발점이며, 자습서에서 복사한 숫자는 그렇지 않다.

정책은 한곳에 두라. logrotate가 파일을 회전하고 rsyslog도 그것을 회전하면 두 번째 회전이 이기고 첫 번째의 명명 규칙은 어수선함으로 남는다. 소유자를 정하고 다른 회전을 끄고 그 결정을 정책 옆에 적어라.

rsyslog 문서는 라우팅과 동작 모델을 다루고, 데몬 자체의 로깅 옵션에 대해서는 OpenVPN 서비스 문서가 계속 권위다. 둘 중 어느 것도 당신 대신 보존 정책을 정하지 않는다.

회전 하나와 새 이벤트 하나를 시험하라

회전을 한 번만 강제한 뒤 인증 실패 같은 새 이벤트를 하나 만들어라. 새 레코드가 새 파일에 나타나고 옛 파일이 더는 커지지 않는지 확인하라.

새 파일의 권한도 보라. 다른 소유자로 다시 만드는 회전은 다음 쓰기에서 작성자를 깨뜨리고 충돌처럼 보이는 틈을 만든다. 떠나기 전에 소유자와 모드를 서비스 계정과 비교하라. 이어서 압축 아카이브를 읽을 수 있는지 확인하라. 아무도 열 수 없는 아카이브는 보존이 아니다. 옛 파일의 가장 최근 레코드를 잠깐 읽으면 압축과 권한이 모두 증명된다.

각 단계의 소유자를 기록하며 끝내라. 어느 구성 요소가 쓰고, 어느 것이 회전하며, 보존 정책이 어디에 있는지. 그 기록이 있어야 다음 로깅 사고가 어느 계층이 줄을 떨어뜨렸는지 짐작하는 반나절이 아니라 오 분 점검이 된다.