답변:
단순화하면 다음과 같이 진행됩니다.
커널은 메시지를 ( printk()함수를 사용하여 ) 커널 공간의 링 버퍼에 기록합니다. 이러한 메시지는 /proc/kmsg파일 ( /proc마운트 된 상태로 제공 )과 sys_syslogsyscall을 통해 두 가지 방식으로 사용자 공간 응용 프로그램에 제공됩니다 .
커널의 링 버퍼를 읽고 제어 할 수있는 두 가지 주요 응용 프로그램이 있습니다 : dmesg(1)및 klogd(8). 전자는 링 버퍼의 내용을 인쇄하기 위해 사용자의 요청에 따라 실행되도록 고안되었습니다. 후자는 메시지를 읽 /proc/kmsg거나 마운트하지 않은 sys_syslog경우 호출 하여 메시지를 콘솔이나 콘솔로 /proc보내는 데몬입니다 syslogd(8). 그것은 커널 측면을 다룹니다.
사용자 공간에는가 syslogd(8)있습니다. 이것은 다수의 UNIX 도메인 소켓 (주로 /dev/log다른 소켓 도 구성 가능)에서 수신하고 선택적으로 메시지의 UDP 포트 514를 수신하는 데몬입니다 . 또한 klogd(8)( syslogd(8)걱정하지 않음 ) 메시지를받습니다 /proc/kmsg. 그런 다음이 메시지를의 일부 파일 /log또는 명명 된 파이프에 쓰거나 syslog프로토콜을 통해 UDP 포트 514의 일부 원격 호스트로 보냅니다 /etc/syslog.conf.
사용자 공간 응용 프로그램은 일반적으로이 libc기능 syslog(3)을 사용하여 메시지를 기록합니다. libc이 메시지를 UNIX 도메인 소켓 /dev/log(로 읽는 위치 syslogd(8))으로 전송하지만 응용 프로그램이 chroot(2)-ed이면 메시지가 다른 소켓 (fi to)에 기록 될 수 있습니다 /var/named/dev/log. 물론 이러한 로그를 전송하는 응용 프로그램과 syslogd(8)이러한 소켓의 위치에 동의하는 것이 필수적입니다 . 이러한 이유로 syslogd(8)표준 이외의 추가 소켓을 수신하도록 구성 할 수 있습니다 /dev/log.
마지막으로, syslog프로토콜은 데이터 그램 프로토콜 일뿐입니다. 아무것도 syslog(3)기능을 libc완전히 무시하고 응용 프로그램이 syslog 데이터 그램을 UNIX 도메인 소켓 (신임 정보가 소켓을 열 수있는 경우)으로 전송하는 것을 막을 수는 없습니다. 데이터 그램의 형식이 올 바르면 syslogd(8)마치 메시지를 통해 보낸 것처럼 사용할 수 있습니다 syslog(3).
물론 위의 내용은 "고전적인"로깅 이론 만 다룹니다. 다른 데몬 (예 : rsyslog및 syslog-ng)은 일반을 대체 할 수 있으며 syslogd(8)암호화 된 TCP 연결을 통해 원격 호스트에 메시지를 보내거나 고해상도 타임 스탬프를 제공하는 등 모든 종류의 멋진 작업을 수행 할 수 있습니다 . 그리고 systemd리눅스의 유닉스 부분을 천천히 포식하고 있습니다. systemd자체 로깅 메커니즘이 있지만 그 이야기는 다른 사람이 이야기해야합니다. :)
* BSD 세계와의 차이점 :
* BSD에는이 없으며 klogd(8), /proc존재하지 않거나 (OpenBSD에) 존재하지 않거나 (FreeBSD와 NetBSD에) 거의 사용되지 않습니다. syslogd(8)문자 장치에서 커널 메시지를 읽고 /dev/klog, 그리고 dmesg(1)사용하는 /dev/kmem커널 이름을 디코딩 할 수 있습니다. 오직 OpenBSD만이 /dev/log있습니다. FreeBSD는 두 개의 유닉스 도메인 소켓을 사용 /var/run/log하고 var/rub/logpriv대신 NetBSD는 /var/run/log.
rsyslog는 klogd(8)근본 원인으로 돌아 가지 않기 때문에 사용하지 않는다 . 그래도 내 기억은 실패 할 수 있습니다. 어쨌든, 내가 말했듯이, 나는 "고전적인"벌목 만 다루려고했다.
rsyslogd실행 및 하나 우분투 12.04 syslog-ng실행하고 모두 파일을 가지고 /proc/kmsg에 따라 개방 lsof즉, klogd사용되지 않았다. 내가 주목 한 또 다른 흥미로운 점은 /proc/kmsgsyslog 데몬이 실행 중이 아니고 예를 들어 cat텍스트 편집기로 로그 메시지 를 볼 수 있으면 로그 메시지가 파일에 저장된다는 것입니다 . 그러나 메시지를 본 후 사라지기 때문에 해당 메시지를 한 번만 볼 수 있습니다. 마지막으로, 실행 dmesg해도 /proc/kmsg파일 내용이 지워지지 않습니다 .
/proc/kmsg은 일반 파일이 아니며 거기에 "저장된"것도없고 단지 커널의 링 버퍼에 대한 뷰일뿐입니다. 당신은 그것을 읽을 수있는 cat더없는 정확하게 때문에 klogd(8)(당신이 실행해야 실행 klogd(8), cat /proc/kmsg차단하는 것입니다). 보다 dmesg(1)메시지를 읽습니다 . 당신이 그것을 말하면 버퍼를 지울 수도 있습니다. /dev/kmsg/proc/kmsg
systemd has its own logging mechanisms, but that story would have to be told by somebody else. :)-당신은 재능이 있다고 말해주십시오 :-)
다른 답변은 저자가 말했듯이 Linux에서 "클래식 로깅"을 설명합니다. 오늘날 많은 시스템에서 작동하는 방식이 아닙니다.
커널 메커니즘이 변경되었습니다.
커널은 인 메모리 버퍼로 출력을 생성합니다. 응용 프로그램 소프트웨어는 두 가지 방법으로 액세스 할 수 있습니다. 로깅 하위 시스템은 일반적으로 이름이 가상 의사 (pseudo-FIFO)로 액세스합니다 /proc/kmsg. 이 로그 정보 소스는 한 번만 읽으므로 로그 리더간에 유용하게 공유 할 수 없습니다. 여러 프로세스가 공유하는 경우 각각 커널 로그 데이터 스트림의 일부만 가져옵니다. 또한 읽기 전용입니다.
그것에 접근하는 다른 방법은 최신 /dev/kmsg문자 장치입니다. 여러 클라이언트 프로세스간에 공유 할 수있는 읽기 / 쓰기 인터페이스입니다. 여러 프로세스가이 프로세스를 공유하면 모두 서로 영향을받지 않고 동일한 완전한 데이터 스트림을 읽습니다. 쓰기 액세스를 위해 파일을 열면 마치 커널에서 생성 된 것처럼 메시지를 커널의 로그 스트림에 삽입 할 수도 있습니다.
/proc/kmsg및 /dev/kmsg비 RFC-5424 형식으로 로그 데이터를 제공합니다.
응용 프로그램이 변경되었습니다.
기본적으로 GNU C 라이브러리의 syslog()기능은 AF_LOCAL이름이 지정된 데이터 그램 소켓 에 연결하고 /dev/log로그 항목을 작성합니다. (BSD C 라이브러리의 syslog()기능은 현재 /var/run/log소켓 이름으로 사용 되며 /var/run/logpriv먼저 시도합니다 .) 물론 응용 프로그램은 직접이 작업을 수행하는 자체 코드를 가질 수 있습니다. 라이브러리 함수는 결국 응용 프로그램 자체의 프로세스 컨텍스트에서 실행되는 코드 (소켓을 열고, 연결하고, 쓰고 닫는 것)입니다.
응용 프로그램은 컴퓨터 의 AF_INET/ AF_INET6데이터 그램 소켓에서 수신 대기하는 경우 UDP를 통해 RFC 5424 메시지를 로컬 RFC 5426 서버로 보낼 수도 있습니다 .
지난 20 년 동안의 daemontools 세계의 압력 덕분에 GNU syslog()D 라이브러리 기능이나 UDP 소켓을 사용하지 않고 로그 데이터를 표준 오류에 뱉어내는 모드에서 많은 데몬이 실행되는 것을 지원 합니다. 일반적인 유닉스 패션.
daemontools 툴셋 제품군을 사용하면 로깅에 많은 유연성이 있습니다. 그러나 일반적으로 온 가족 전체에 대한 아이디어는 각 "주요"데몬은 연관된 "로깅"데몬을 가지고 있다는 것입니다. "main"dæmons는 non-dæmon 프로세스와 동일하게 작동하며 로그 메시지를 표준 오류 (또는 표준 출력)에 기록합니다.이 오류 메시지는 서비스 관리 서브 시스템이 파이프를 통해 연결되도록 정렬합니다 (로그 데이터가 손실되지 않도록 열린 상태로 유지됨). "로깅"dæmon의 표준 입력으로 서비스를 다시 시작하십시오.
모든 "로깅"데몬은 어딘가에 기록하는 프로그램을 실행합니다 . 일반적으로이 프로그램은 표준 입력에서 읽 multilog거나 cyclog엄격하게 크기가 제한되고 자동으로 회전되는 단독 쓰기 디렉토리에 로그 파일을 작성합니다 (나노초 타임 스탬프). 일반적으로 이러한 데몬은 모두 개별 전용 권한이없는 사용자 계정의 분위기에서 실행됩니다.
따라서 각 서비스의 로그 데이터가 개별적으로 처리되는 대규모 분산 로깅 시스템이 생깁니다.
하나는 수 같은 것을 실행 klogd하거나 syslogd또는 rsyslogd데몬 툴즈 가족 서비스 관리 아래에 있습니다. 그러나 데몬 툴 세계는 수년 전에 "로깅"dæmons을 사용하는 서비스 관리 구조가보다 간단한 방식으로 작업을 수행한다는 사실을 깨달았습니다. 모든 로그 스트림을 하나의 거대한 mish-mash로 팬하고 로그 데이터를 구문 분석 한 다음 스트림을 다시 분리하여 별도의 로그 파일로 팬할 필요가 없습니다. 그런 다음 (일부 경우) 측면에 신뢰할 수없는 외부 로그 회전 메커니즘을 볼트로 조입니다. 표준 로그 관리의 일부인 daemontools-family 구조는 이미 로그 회전, 로그 파일 쓰기 및 스트림 분리를 수행합니다.
또한 모든 서비스에서 공통적 인 도구를 사용하는 드롭 권한의 체인 로딩 모델은 로깅 프로그램에 수퍼 유저 권한이 필요하지 않음을 의미합니다. UCSPI 모델은 스트림 대 데이터 그램 전송과 같은 차이점 만 신경 써야한다는 것을 의미합니다.
nosh 툴셋이이를 보여줍니다. 그 아래에서 즉시 실행할 수 있지만 이전 방식으로 rsyslogd커널 /run/log,, 및 UDP 로그 입력을 관리 할 수 있습니다. 그것은 또한 이 일을 로깅 더 "데몬 툴즈 기본"방법을 제공합니다 :
klogd읽고 /proc/kmsg표준 오류에 기록 하는 서비스 . 이것은라는 간단한 프로그램에 의해 수행됩니다 klog-read. 연관된 로깅 dæmon은 표준 입력의 로그 스트림을 /var/log/sv/klogd로그 디렉토리에 공급합니다.local-syslog-read에서 데이터 그램을 읽어 서비스 /dev/log( /run/log단순히 BSD의에) 및 표준 오류에 해당 로그 스트림을 작성합니다. 이 프로그램은라는 프로그램에 의해 수행됩니다 syslog-read. 연관된 로깅 dæmon은 표준 입력의 로그 스트림을 /var/log/sv/local-syslog-read로그 디렉토리에 공급합니다.udp-syslog-read단순히 UDP 시스템 로그 포트에서 수신 그것이로 전송 무엇을 읽고 서비스는 표준 오류에 해당 로그 스트림을 작성합니다. 다시, 프로그램은 syslog-read입니다. 연관된 로깅 dæmon은 표준 입력의 로그 스트림을 /var/log/sv/udp-syslog-read로그 디렉토리에 공급합니다.local-priv-syslog-read데이터 그램을 읽고 /run/logpriv그 로그 스트림을 표준 오류에 기록 하는 서비스입니다 . 다시, 프로그램은 syslog-read입니다. 연관된 로깅 dæmon은 표준 입력의 로그 스트림을 /var/log/sv/local-priv-syslog-read로그 디렉토리에 공급합니다.이 도구 세트에는 export-to-rsyslog하나 이상의 로그 디렉토리 (비 침입 로그 커서 시스템 사용)를 모니터링 하고 네트워크를 통해 RFC 5424 형식의 새 항목을 지정된 RFC 5426 서버로 보낼 수 있는 도구 가 함께 제공됩니다 .
systemd에는 단일 모 놀리 식 로그 관리 프로그램이 systemd-journald있습니다. 이는 systemd가 관리하는 서비스로 실행됩니다.
/dev/kmsg커널 로그 데이터를 읽습니다 ./dev/log(기호 링크 /run/systemd/journal/dev-log)를 읽습니다 syslog().AF_LOCAL를 /run/systemd/journal/stdout위해 스트림 소켓에서 청취 합니다.AF_LOCAL를 /run/systemd/journal/socket위해 데이터 그램 소켓에서 수신 대기합니다 sd_journal_sendv()./run/log/journal/또는 /var/log/journal/.AF_LOCAL데이터 그램 소켓에 연결할 수있는 경우 /run/systemd/journal/syslog저널 데이터를 작성합니다./dev/kmsg메커니즘을 사용하여 저널 데이터를 커널 버퍼에 씁니다 .이 프로그램이 충돌하거나 서비스가 중지되면 시스템 전체에 나쁜 일이 발생합니다.
systemd 자체는 표준 출력과 (일부) 서비스의 오류가 /run/systemd/journal/stdout소켓에 연결되도록합니다 . 따라서 일반적인 방식으로 표준 오류에 기록되는 dæmon은 출력을 저널로 보냅니다.
이것은 klogd, syslogd, syslog-ng 및 rsyslogd를 완전히 대체합니다.
이것들은 이제 시스템 특정 적이어야합니다. 시스템화 된 시스템에서는 서버의 끝이 아닙니다 /dev/log. 대신 두 가지 접근 방식 중 하나를 사용합니다.
/run/systemd/journal/syslog(기억한다면) systemd-journald저널 데이터를 연결하고 쓰려고 시도 하는 서버의 끝이 됩니다. 몇 년 전에 rsyslogd의 imuxsock입력 방법을 구성했을 것 입니다.imjournal입력 방법을 구성 합니다.