상황은 이렇습니다.
syslog-ng 버전 3.15가 있습니다. TLS와 비 TLS 전송을 사용할 때 로그가 다른 것으로 나타났습니다.
loggen -i(TLS가 아닌, 이전 RFC3164 형식) 명령을 사용하여 로그를 보낼 때 다음 메시지를 받은 것으로 나타났습니다 .
6월 26일 18:19:39로컬 호스트prg00000[1234]: seq: 0000000000, 스레드: 0000, runid: 1530026379, 스탬프: 2018-06-26T18:19:39 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADD DPADDPADDPADDPAD DPADDPADDD
(TLS가 아닌 최신 RFC5424 형식) 명령을 사용할 때 loggen -i -P메시지는 다음과 같습니다.
6월 26일 18:19:28192.168.1.10 256<38>1 2018-06-26T18:19:26+03:00로컬 호스트prg00000 1234 - - <U+FEFF> seq: 0000000000, 스레드: 0000, runid: 1530026366, 스탬프: 2018-06-26T18:19:26 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADD ADDPADDP ADDPADPADDPADPAD
TLS loggen -i -U(TLS, 이전 RFC3164 형식) 명령을 사용할 때는 작동하지 않습니다.
[root@localhost ~]# loggen -i -U 192.168.1.7 6514
Send error Connection reset by peer, results may be skewed.
average rate = 606.59 msg/sec, count=7, time=0.011, (average) msg size=256, bandwidth=151.56 kB/sec
TLS loggen -i -P -U(TLS, 최신 RFC5424 형식) 명령을 사용할 때 로그는 다음과 같습니다.
6월 26일 18:19:13로컬 호스트prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026353, stamp: 2018-06-26T18:19:13 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADD DPADDPADDPAD
$HOST 매크로는 두 번째 열을 사용하여 호스트별로 로그를 분할한다는 것을 알고 있습니다. TLS와 비 TLS 사이를 전환할 때 두 번째 열 대신 TLS를 사용하는 것은 실망스러울 수 있습니다 localhost. IP-address어떻게든 이 상황을 피할 수 있을까요?
답변1
문제는 프레임에 있다는 것을 알았습니다. syslog-ng 및 loggen의 syslog() 드라이버는 메시지 길이 + msg 예: "256 <13>1 2018-07-09T16:23:25+02:00 localhost . ..." 프레임과 함께 RFC5424 형식의 메시지도 보냅니다. 반면에 tcp() 또는 network() 드라이버는 RFC5424 형식의 메시지를 구문 분석할 수 있지만(flags(syslog-protocol) 옵션이 사용되는 경우) 프레이밍을 기대하지 않습니다.
해결 방법은 loggen에서 프레이밍을 비활성화하고(loggen에 "-F" 옵션 사용) network() 소스에서 "flags(syslog-protocol)" 옵션을 사용하는 것입니다.
그러나 이는 loggen 문제만 해결합니다. 로그 소스가 프레임된 로그 메시지를 보내는 경우 tcp() 소스 드라이버에 동일한 문제가 발생합니다.
syslog()를 사용하면 소스 드라이버는 loggen 또는 syslog()의 프레임을 처리하고 예상합니다.
그런데 tcp(), upd() 드라이버는 더 이상 사용되지 않으며 syslog-ng에 따라 최신 network() 드라이버를 사용하는 것이 좋습니다.문서.