s6, runit, perp, nosh, daemontools-encore 등이 포함된 시스템 이것이 서비스 관리가 작동하는 방식입니다. 각 주요 서비스에는 독립적으로 모니터링할 수 있는 별도의 관련 로그 파일 세트와 분산형 로깅 메커니즘이 있습니다.

그러나 systemd는 이와 같이 작동하지 않습니다. 특정 서비스에 대해 별도의 "관련 로그 파일"이 없습니다. 모니터링할 파일이 없습니다.

모든 로그 출력은 단일 중앙 데몬으로 유입되고 systemd-journald해당 데몬은 이를 단일 스트림에 기록합니다 /{run,var}/log/journal/.

옵션 은 관련 서비스 이름으로 태그가 지정된 모든 로그 항목과 함께 단일 중앙 로그에서 인쇄되는 내용을 필터링하는 사후 처리 필터 -u입니다 . journalctl모든 것이 부채꼴 모양으로 펼쳐져 있으며 이를 필터링하여 (대략) 원래 형태로 다시 분리해야 합니다.

시스템적인 방법은 적절한 필터를 추가 journalctl -f하거나 시스템 특정 API를 사용하여 로그에 대한 자체 프로그램을 직접 작성하는 것입니다.

추가 읽기

• https://unix.stackexchange.com/a/294206/5132

1.) Linux 배포판이 journald전체 범위를 사용하는 경우 다음과 같은 읽기 쉬운 기존 로그 파일은 없습니다.@JdeBP말하는. 로그 파일은 기존 로그 파일 도구로 구문 분석하기 어려운 바이너리 형식을 사용합니다.

2.) journalctl -u {service}필요한 정보가 있는 경우 journalctl -f -u {service}출력을 사용하여 로그를 구문 분석하고 원하는 반응을 트리거하는 프로그램에 파이프할 수 있습니다. 그 이상의 내용은 선택한 Linux 배포판에 따라 다를 수 있습니다.

예를 들어 Debian 9(Stretch)는 기본 구성에서 journald기존 syslog 입력 소켓을 유지합니다. /dev/log그러나 rsyslogd설치된 경우 journald수신 syslog 메시지를 전달하도록 구성됩니다.

journald다른 Linux 배포판은 다르게 구조화된 기존 syslog 데몬과 관계가 있을 수 있습니다.