☰

추가 읽기

tag-icon • tag-icon centos systemd syslog rsyslog
추가 읽기

syslog(3)중앙 로거에 애플리케이션 로그를 기록하는 데 사용하고 싶습니다 . 애플리케이션은 동일한 서브넷에 있는 컴퓨터 그룹에서 실행됩니다.

(아직) 시스템(비애플리케이션) 로그를 중앙 서버로 캡처하는 데 관심이 없습니다. 각 로컬 시스템의 시스템 로그에 애플리케이션 로그를 캡처하는 데 관심이 없습니다.

목적은 syslog(3)"local0"-"local7"을 사용하여 시스템 로깅을 건너뛰고 대신 UDP(아마도 포트 514)를 통해 로거에 쓰는 것입니다.

이는 일반적인 질문(애플리케이션 로그를 시스템 로그로 리디렉션하는 방법)과 반대되는 것 같습니다.

현재 저는 Centos systemd/rsyslog 래시업의 중요성에 대해 생각하고 있습니다. 분명히 말씀드리지만, 앞으로 며칠 내에 이 문제가 해결되기를 바랍니다.

나처럼 답을 찾고 있었지만 즉각적인 행운을 얻지 못한 다음 사람에게 질문을 했습니다. :)

답변1

목적은 syslog()"local0"-"local7"을 사용하여 시스템 로그를 건너뛰는 것 입니다.

당신은 그것을 달성하지 못할 것입니다. 라이브러리 syslog()기능은 systemd 로그에 기록됩니다. 라이브러리와의 통신을 위해 잘 알려진 소켓을 수신하는 /dev/log서버는 rsyslogd. 이것은 systemd-journald. rsyslogd예반대편에 붙어있는, 라이브러리 기능은 이에 대해 이야기하지 않습니다 systemd-journald. 구성을 아무리 수정해도 rsyslog이 내용은 변경되지 않습니다.

거치지 않고 무언가를 보내는 유일한 방법은 systemd-journald일부를 사용하는 것입니다.다른목적지까지의 경로,아니요syslog()잘 알려진 소켓과 통신하기 위한 라이브러리 함수

아이러니하게도 애플리케이션 로그를 위한 정확하고 간단한 위치는 아마도 표준 오류일 것입니다. 표준 오류를 네트워크를 통해 원격 로그 수집기로 전송하는 프로그램과 통신하는 파이프에 연결합니다.

이와 같은 작업에 대해 내가 선호하는 설정은 daemontools 서비스 관리자 제품군에서 "기본" 서비스로 애플리케이션을 실행하는 것입니다.

  • 애플리케이션은 표준 오류에 기록됩니다.
  • 일반적인 daemontools 스타일의 서비스 관리에는 표준 입력이 애플리케이션의 표준 오류로 파이프되는 로깅 서비스가 있습니다. 서비스 관리자는 "기본" 서비스와 "로그" 서비스 사이에 이러한 파이프를 설정하는 일을 담당합니다.
  • 이러한 로그 서비스는 cyclog, multilog, s6-log, svlogd또는 이러한 서비스 중 일부를 실행하고 로그를 로컬(엄격히 제한된 크기, 자동 회전, 애플리케이션에서 격리) 로그 디렉터리에 덤프합니다.
  • 추가 서비스는 이러한 로그 디렉터리를 모니터링하고 네트워크를 통해 logstash 또는 유사한 기능을 실행하는 중앙 집중식 로그 서버에 새로운 정보를 제공합니다. 내 export-to-rsyslog도구는 이를 위해 설계되었습니다.

이렇게 하면 다음과 같은 이점이 있습니다.

  • 로컬, 즉시 액세스 가능, 애플리케이션별, 별도(다른 항목과 혼합되거나 압도되지 않음)의 최근 로그가 있습니다.
  • 로그 서버에 대한 불안정한 네트워크 연결은 애플리케이션에 역압을 가하지 않습니다(애플리케이션 표준 오류가 네트워크를 통해 전달되거나 네트워크를 통해 즉시 중계되는 서버에 직접 전달되는 보다 직접적인 모델에서와 마찬가지로). 프로세스);
  • 네트워크 전송은 로컬 로깅에 비해 완전히 비침해적이며 나중에 설정할 수 있고(중앙 집중식 Logstash와 같은 것이 필요한 지점까지 데이터 볼륨이 증가하는 경우) 영향을 주지 않고 네트워크를 재구성(전송 애플리케이션 로그 추가/제거)할 수 있습니다. 그것과;
  • 극단적인 경우에는 최근 로그 데이터가 불안정하거나 실수로 지워진 로그 서버에 재생되도록 할 수도 있습니다.

추가 읽기

관련 정보