원격 syslog TLS 연결이 끊겨도 로컬 로그 처리가 멈추지 않게 점검하기

rsyslog의 TLS 전달에는 TLS-capable stream driver뿐 아니라 TLS mode 활성화와 인증 모드·허용 peer 확인이 필요합니다. TCP 전달에 action queue를 두면 원격 수신기 장애가 즉시 동기 전달을 막는 상황을 줄일 수 있습니다.

queue는 무제한 또는 무손실 보존을 뜻하지 않습니다. 종류·크기·디스크 여유·재시도·저장 정책과 종료 방식에 따라 대기와 유실 위험이 달라집니다.

연결 실패와 로그 대기는 서로 다른 문제입니다

원격 syslog로 전달하던 로그가 멈추면 오류를 인증 단계와 전달 대기 단계로 나눕니다. 인증서 체인, peer 이름, TLS mode가 맞지 않으면 연결 검증이 실패할 수 있습니다. 수신기나 경로가 중단된 경우는 인증서가 맞아도 전달되지 않습니다. rsyslog omfwd 문서는 TLS-capable driver와 mode 설정이 필요하며 TCP 전달에 queue를 정의해 장애의 차단 영향을 줄이도록 권합니다.

action(
    type="omfwd"
    target="logs.example.invalid"
    port="6514"
    protocol="tcp"
    StreamDriver="ossl"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.invalid"
    queue.type="linkedList"
)

driver와 mode, 상대 이름을 각각 대조합니다

1. 설정 target에 사용한 호스트 이름과 실제 연결 주소를 구분합니다. 이름으로 연결하면 시스템 resolver가 연결 시마다 주소를 찾을 수 있습니다.
2. StreamDriver가 ossl, gtls, mbedtls 등 TLS 지원 driver인지 확인합니다. driver 이름만 적는다고 TLS가 자동으로 켜지는 것은 아닙니다.
3. StreamDriverMode가 TLS mode인 1인지 살핍니다. 명시적인 mode 0은 평문 TCP이며, strict compatibility 설정은 생략된 mode 처리에 영향을 줄 수 있습니다.
4. StreamDriverAuthMode와 CA 신뢰 설정이 의도와 맞는지, StreamDriverPermittedPeers가 인증서에서 확인할 peer 이름과 맞는지 대조합니다.
5. 그 다음 연결 거부·인증서 검증·이름 불일치·수신기 응답 오류 중 어떤 단계에서 실패했는지 로그와 수신기 측 기록을 비교합니다.

action queue는 흐름을 분리하지만 용량은 유한합니다

rsyslog queue 문서는 action queue가 기본적으로 direct, 즉 별도 대기열 없이 동작한다고 설명합니다. linked-list 같은 memory queue를 action에 두면 출력 작업이 지연되더라도 메시지를 잠시 쌓아 둘 수 있습니다. disk-assisted queue는 메모리 queue가 일정 수위에 이르면 disk queue로 spill하는 방식이지, 항상 디스크에 동기 저장하는 순수 disk queue가 아닙니다. queue.saveOnShutdown=on은 정상적인 rsyslog 종료 때 메모리 부분을 저장하는 데 쓰일 수 있지만 프로세스 kill, OOM, 시스템 crash 또는 전원 손실 때는 실행되지 않습니다. 순수 disk queue도 checkpoint와 file sync 같은 설정이 내구성 수준에 영향을 줍니다.

장애 대비 queue는 예상 메시지 수, outage 길이, 디스크 허용량, discard 정책, 재시도와 회복 속도를 함께 계산해야 합니다. 큐가 가득 차도 입력이 계속된다고 가정하지 마세요. action queue는 별도 설정이므로 문제가 난 바로 그 action 블록과 상태를 확인해야 합니다.

변경보다 먼저 해당 action의 실제 상태를 수집합니다

설정에서 action과 target을 찾고 TLS 오류와 queue 상태를 나눠 기록합니다. peer 검증 오류라면 허용 이름과 인증서 체인을, 연결 재시도 중이라면 queue 크기와 사용량을 살핍니다. 수신기에서 메시지가 보이지 않는다고 로컬 입력도 버려졌다고 단정하지 말고 입력·규칙·출력 경계를 나누어 확인합니다. queue에 남은 메시지가 장기 보존된다는 뜻도 아닙니다.

‘TLS 설정’과 ‘저장 보장’을 한 문장으로 묶지 않습니다

대표적인 오답은 StreamDriver=ossl만 보고 TLS가 적용됐다고 생각하거나, queue.type=linkedList만 보고 outage 동안 로그가 안전하게 보존된다고 여기는 것입니다. TLS driver와 mode는 별개이며, TLS 연결의 상대 이름 검사도 확인해야 합니다. queue는 전달 지연을 흡수하는 메커니즘이고, 보존 기간과 crash 내구성은 유형·용량·디스크·종료 조건의 결과입니다. 이 글의 설정은 구조를 읽는 연습용이며 실제 장비에 적용할 운영 정책이 아닙니다.