사례 1:

사례 1:

사례 1:

다음 syslog 수신 메시지의 경우,

<14>Mar 22 11:12:06 RT_FLOW: RT_FLOW_SESSION_CREATE: session created 1.2.3.4/62963->23.58.169.35/443 0x0 junos-https 6.7.8.9/32359->23.58.169.35/443 0x0 source rule 1 N/A N/A 6 1 Trust Untrust 60471 N/A(N/A) ge-0/0/1.0 UNKNOWN UNKNOWN UNKNOWN

syslog-ng성공적으로 추가되었습니다CPU 이름타임스탬프( Mar 22 11:12:06)와 메시지 유형( ) RT_FLOW사이


사례 2:

하지만, 다음 syslog 수신 메시지의 경우,

<14> Mar 22 11:04:17 206.133.74.126 03362 auth:  User 'sup_ogr' logged in from 206.133.74.127 to SSH session

특히, 타임스탬프( Mar 22 11:04:17)와 메시지 유형( auth) 사이에 IP 주소가 이미 존재합니다.

syslog-ng할 수 없다...을 더한CPU 이름타임스탬프와 메시지 유형 사이

사용된 구성은 다음과 같습니다. use_dns (yes);&keep_hostname (yes);


  1. 두 번째 경우에는 syslog 메시지에 다음과 일치하는 IP가 있습니까?RFC 5424기준?

  2. 그렇다면 타임스탬프와 메시지 유형 사이에 호스트 이름을 설정하려면 어떤 구성이 필요합니까?

답변1

나는 syslog-ng에 대해 잘 모르지만 rsyslog와 마찬가지로 레거시 syslog 메시지를 구문 분석하기 위해 경험적 방법을 사용한다고 가정합니다(다른 경험적 방법이 있는 것 같습니다).

표시된 메시지는 이상한 형식이라는 점에 유의해야 합니다. RFC3164는 웹에서 일반적으로 볼 수 있는 내용을 설명하며, 여기서 두 번째 형식은 거기에서 설명하는 것과는 거리가 멀습니다. 가능하다면 가장 좋은 해결책은 보낸 사람이 형식을 수정하여 규격을 더욱 준수하도록 하는 것입니다.

답변2

예, 두 메시지는 유사하지만 RFC3164에 설명된 syslog 메시지 형식을 정확하게 따르지는 않습니다. 자세한 내용은 이 페이지와 다음 페이지를 참조하세요.syslog-ng 문서. syslog-ng도 이러한 잘못된 메시지를 구문 분석하려고 시도하지만 완벽하게 수행되지는 않을 수 있습니다. 다음을 시도해 볼 수 있습니다.

  • 보내는 호스트나 애플리케이션을 확인하여 올바른 형식의 메시지를 보내도록 조정할 수 있는지 확인하세요.
  • syslog-ng는 메시지의 모든 필드를 구문 분석할 수 있지만 올바른 필드는 구문 분석할 수 없습니다. 이 메시지에 대한 매크로 값을 확인해 볼 수도 있고 어쩌면메시지 형식을 올바르게 지정하기 위한 템플릿 만들기
  • 다른 모든 방법이 실패하면 다음을 작성할 수 있습니다.Python의 사용자 정의 syslog-ng 파서이 로그 메시지를 구문 분석하세요.

HTH, 로버트

관련 정보