Journald - 보관된 로그를 로깅 소켓으로 다시 보냅니다.

Journald - 보관된 로그를 로깅 소켓으로 다시 보냅니다.

systemd및 가 모두 포함된 장치가 있습니다 rsyslog. 로컬 로깅 및 원격 로깅을 위한 기본 메커니즘입니다 journald. rsyslogrsyslog는 항상 실행되는 것은 아니며 디버깅이 필요할 때만 시작됩니다.

rsyslog가 시작된 후에는 해당 시점부터 발생한 이벤트만 전달합니다. 현재 로그에서 사용 가능한 모든 로그를 전달하려고 합니다.

이를 수행하는 올바른 방법은 $ModLoad imjournalrsyslog를 활성화하는 것 입니다 /etc/rsyslog.conf. 이렇게 하면 rsyslog가 로그의 아카이브 파일을 읽을 수 있습니다.

내가 사용하고 있는 임베디드 시스템에는 rsyslog용 imjournal 모듈이 없으며 해결 방법을 찾고 있습니다.

한 가지 해결 방법은 Journald가 rsyslog가 수신 대기 중인(현재 활성 상태) 소켓으로 모든 이전 아카이브 로그를 다시 보내도록 하는 것입니다.

이를 수행할 수 있는 방법이 있습니까?

답변1

Journald에는 실제로 그러한 기능이 제공되지 않습니다.

이것Journald.conf 매뉴얼 페이지다음 제한사항이 문서화되어 있습니다 ForwardToSyslog=.

syslog로 전달이 활성화되어 있지만 소켓에서 메시지를 읽는 것이 없으면 syslog로 전달해도 효과가 없습니다.

이것이 초기에 시작된 메시지가 손실되는 이유입니다. 매뉴얼 페이지에는 다음과 같은 내용도 나와 있습니다.

[imjournal]을 사용하면 메시지를 즉시 읽을 필요가 없으므로 저널 데몬이 부팅 후반에만 시작되어 시스템 시작 이후 모든 메시지에 액세스할 수 있습니다.

그렇기 때문에 이 방법을 추천합니다.

rsyslog가 처음 시작될 때 시작 후 로그에 저장된 메시지를 공급하고 journalctlrsyslog를 사용하여 읽고 loggerrsyslog에 공급하여 "kludge"를 수행할 수 있다고 생각합니다. 어쩌면 다음과 같이 간단한 것이 작동할 수도 있습니다.

journalctl -b | logger -u /run/systemd/journal/syslog

메시지에 날짜와 태그를 추가하려고 시도하더라도 logger최종 효과는 전달된 메시지와 다르게 보일 수 있습니다... 아마도 그보다 더 원시적이거나 낮은 수준이 필요할 수도 있고 logger, journalctlrsyslog 형식이 되도록 출력 형식을 다시 지정할 수도 있습니다. ...

이 솔루션에는 초기 피드와 로그 전달 사이에 일부 메시지가 손실(또는 중복)될 가능성이 있기 때문에 경쟁 조건이 있습니다.

저널에서 일하는 것이 확실히 더 나은 솔루션입니다. 모든 systemd 및 rsyslog 소프트웨어가 모두 장치용으로 컴파일되고 빌드된 후에 사용할 수 없는 이유가 궁금합니다. 따라서 적어도 기술적으로 imjournal 모드도 빌드하는 것이 가능합니다... 아마도 크로스 컴파일이 관련되어 있을 수 있습니다. 어쩌면 systemd 라이브러리에 연결하는 데 어려움이 있지만 해결할 수 있는 문제라고 확신하므로 문제를 제기하여 작동하게 하는 것이 좋습니다.


고려해야 할 또 다른 솔루션은 syslog 프로토콜 및 데몬 대신 기본 로깅 원격 프로토콜을 사용하여 로깅을 중앙 집중화하는 것입니다.

가지다시스템 로그 원격원격 호스트에서 "수신기" 모드로 실행하여 내장 장치로부터 항목을 수신하고 로컬에 저장할 수 있습니다. 그리고시스템 로그 업로드, 내장된 장치에서 실행하여 로그 데이터를 원격 호스트로 푸시할 수 있습니다.

메시지를 syslog 형식으로 변환할 필요가 없으므로 조기 시작 메시지와 모든 메타데이터가 모두 보존됩니다. 또한 내장된 장치에서 rsyslog 데몬을 로컬로 계속 실행할 필요가 없다는 장점도 있습니다.

(저널은 또한 다음을 실행할 수 있는 "풀" 모델을 지원합니다.systemd-저널-gatewayd임베디드 장치에서 가져오도록 systemd-journal-remote를 구성합니다. )

관련 정보