Linux 로그인 이해

간단히 말해서 대략 다음과 같습니다.

커널은 이 printk()함수를 사용하여 커널 공간의 링 버퍼에 메시지를 기록합니다. 이러한 메시지는 파일 /proc/kmsg( /proc설치된 경우)과 sys_syslog시스템 호출을 통해 두 가지 방법으로 사용자 공간 애플리케이션에 제공될 수 있습니다 .

커널의 링 버퍼를 읽을 수 있고 어느 정도 제어할 수 있는 두 가지 주요 응용 프로그램이 있습니다: dmesg(1)및 klogd(8). 전자는 링 버퍼의 내용을 인쇄하기 위해 사용자의 요청에 따라 실행되도록 고안되었습니다. 후자는 메시지를 읽고 /proc/kmsg(또는 설치되지 않은 sys_syslog경우 호출하여) 또는 콘솔 /proc로 보내는 데몬입니다 . syslogd(8)이는 커널 측면을 다룹니다.

사용자 공간에는 여러 UNIX 도메인 소켓(주로 UNIX 도메인 소켓 이지만 다른 것도 구성될 수 있음)을 syslogd(8)수신하고 선택적으로 UDP 포트 514에서 정보를 수신하는 데몬입니다 . 또한 ( 상관없음 ) /dev/log로부터 메시지를 수신합니다 . 그런 다음 에 구성된 대로 이러한 메시지를 일부 파일 또는 명명된 파이프에 쓰거나 일부 원격 호스트(프로토콜을 통해 UDP 포트 514)로 보냅니다 .klogd(8)syslogd(8)/proc/kmsg/logsyslog/etc/syslog.conf

사용자 공간 애플리케이션은 일반적으로 이 libc기능을 사용하여 syslog(3)메시지를 기록합니다. libc이러한 메시지는 UNIX 도메인 소켓으로 전송되지만 /dev/log(이를 통해 읽혀짐 syslogd(8)) 애플리케이션이 chroot(2)-ed되면 메시지는 결국 다른 소켓(fi에서 )에 기록될 수 있습니다 /var/named/dev/log. 물론 이러한 로그를 보내는 애플리케이션이 이러한 소켓의 위치에 동의하는 것이 syslogd(8)중요합니다 . 이러한 이유로 syslogd(8)표준 소켓이 아닌 다른 소켓에서 수신 대기하도록 구성하는 것이 가능합니다 /dev/log.

결국 syslog프로토콜은 단지 데이터그램 프로토콜일 뿐입니다. 응용 프로그램의 자격 증명을 통해 syslog(3)기능을 완전히 우회하여 소켓을 열 수 있는 경우 응용 프로그램이 UNIX 도메인 소켓에 syslog 데이터그램을 보내는 것을 막을 수 있는 방법은 없습니다 libc. 데이터그램의 형식이 올바른 경우 syslogd(8)메시지를 보내는 것처럼 사용할 수 있습니다 syslog(3).

물론 위의 내용은 "고전적인" 벌목 이론만을 다루고 있습니다. 다른 데몬(예: 언급한 데몬 rsyslog및 언급한 데몬 syslog-ng)은 일반 데몬을 대체할 수 syslogd(8)있으며 암호화된 TCP 연결을 통해 원격 호스트에 메시지 보내기, 고해상도 타임스탬프 제공 등과 같은 모든 종류의 멋진 작업을 수행할 수 있습니다. 또한 systemdLinux의 UNIX 측면도 서서히 잠식되고 있습니다. systemd자체 로깅 메커니즘이 있지만 그 내용은 다른 사람이 말해야 합니다. :)

*BSD 세계와의 차이점:

*BSD에서는 사용할 수 없으며 klogd(8), /proc존재하지 않거나(OpenBSD에서) 대부분 사용되지 않습니다(FreeBSD 및 NetBSD에서). syslogd(8)문자 장치에서 커널 메시지를 읽고 /dev/klog이를 dmesg(1)사용하여 /dev/kmem커널 이름을 디코딩합니다. OpenBSD만이 하나를 가지고 있습니다 /dev/log. FreeBSD는 두 개의 UNIX 도메인 소켓을 사용하는 /var/run/log반면 var/rub/logprivNetBSD는 하나를 사용합니다 /var/run/log.

또 다른 대답은 저자가 말했듯이 Linux의 "클래식 로깅"을 설명합니다. 오늘날 많은 시스템은 이런 방식으로 작동하지 않습니다.

핵심

커널 메커니즘이 변경되었습니다.

커널은 메모리 버퍼에 대한 출력을 생성합니다. 응용 프로그램 소프트웨어는 두 가지 방법으로 액세스할 수 있습니다. 로깅 하위 시스템은 일반적으로 이라는 의사 FIFO로 이에 액세스합니다 /proc/kmsg. 이 로그 정보 소스는 한 번만 읽혀지기 때문에 로그 판독기 간에 공유할 수 없습니다. 여러 프로세스가 공유하는 경우 각 프로세스는 커널 로그 데이터 스트림의 일부만 가져옵니다. 또한 읽기 전용입니다.

이에 액세스하는 또 다른 방법은 최신 /dev/kmsg캐릭터 장치입니다. 이는 여러 클라이언트 프로세스 간에 공유할 수 있는 읽기-쓰기 인터페이스입니다. 여러 프로세스가 이를 공유하는 경우 서로 영향을 주지 않고 모두 동일한 완전한 데이터 스트림을 읽습니다. 쓰기 액세스를 위해 열면 메시지가 커널에서 생성된 것처럼 커널의 로그 스트림에 메시지를 삽입할 수도 있습니다.

/proc/kmsg/dev/kmsgRFC-5424가 아닌 형식으로 로그 데이터를 제공합니다 .

적용분야

신청서가 변경되었습니다.

GNU C 라이브러리의 주요 기능은 명명된 데이터그램 소켓 syslog()에 연결 하고 여기에 로그 항목을 쓰려고 시도합니다. (BSD C 라이브러리의 함수는 이제 소켓 이름을 가져와 먼저 시도합니다.) 물론 응용 프로그램은 이를 직접 수행하기 위한 자체 코드를 가질 수 있습니다. 결국, 라이브러리 함수는 애플리케이션 자체 프로세스의 컨텍스트에서 실행되는 코드(소켓 열기, 연결, 쓰기 및 닫기)일 뿐입니다.AF_LOCAL/dev/logsyslog()/var/run/log/var/run/logpriv

응용 프로그램이 컴퓨터의 AF_INET/datagram 소켓에서 수신 대기 중인 경우 UDP를 통해 로컬 RFC 5426 서버에 RFC 5424 메시지를 보낼 수도 있습니다 .AF_INET6

지난 20년 동안 daemontools 세계의 압력으로 인해 많은 데몬은 syslog()GNU C 라이브러리 기능이나 UDP 소켓을 사용하지 않고 로그 데이터를 일반 Unix 방식으로 표준 오류로 내보내는 모드에서 실행을 지원합니다.

일반적으로 로그 관리에는 nosh 및 daemontools 시리즈를 사용합니다.

daemontools 도구 제품군을 사용하면 로깅이 매우 유연해집니다. 그러나 일반적으로 시리즈 전체의 아이디어는 모든 "기본" 데몬에 연관된 "로깅" 데몬이 있다는 것입니다. "기본" 데몬은 데몬이 아닌 것처럼 작동하고 로그 메시지를 표준 오류(또는 표준 출력)에 기록하며, 서비스 관리 하위 시스템은 파이프(로그 데이터가 손실되지 않도록 열려 있는 상태로 유지됨)를 통해 연결을 준비합니다. 서비스 재시작)을 "로깅" 데몬의 표준 입력으로 보냅니다.

모든 "로깅" 데몬은 로깅 프로그램을 실행합니다.어딘가에. 일반적으로 이 프로그램은 표준 입력에서 multilog읽고 cyclog크기가 엄격하게 제한되고 자동으로 회전되는 쓰기 전용 디렉터리에 로그 파일을 씁니다(나노초 타임스탬프). 일반적으로 이러한 데몬은 권한이 없는 전용 사용자 계정의 후원 하에서도 실행됩니다.

따라서 각 서비스의 로그 데이터가 독립적으로 처리되는 대규모 분산 로깅 시스템이 됩니다.

하나할 수 있는daemontools 시리즈 서비스 관리 klogd와 유사한 것을 실행하십시오 syslogd. rsyslogd그러나 daemontools 세계는 "로깅" 데몬이 있는 서비스 관리 구조가 더 간단한 방법으로 작업을 수행하는 데 적합하다는 것을 수년 전에 깨달았습니다. 모든 로그 스트림을 하나의 거대한 잡동사니로 분산시키고, 로그 데이터를 구문 분석한 다음, 스트림을 다시 별도의 로그 파일로 분산시킨 다음 (경우에 따라) 신뢰할 수 없는 외부 로그 회전 메커니즘을 측면에 추가할 필요가 없습니다. 표준 로그 관리의 일부인 daemontools 제품군 구조이미 완료했습니다로그 회전, 로그 파일 쓰기 및 스트림 분리.

또한 모든 서비스에 공통된 도구를 사용하여 권한을 제거하는 체인 로딩 모델은 로거에 수퍼유저 권한이 필요하지 않음을 의미합니다. UCSPI 모델은 스트림 전송과 데이터그램 전송과 ​​같은 차이점에만 관심이 필요함을 의미합니다.

nosh 도구 세트는 이를 구현합니다. 비록 하나이지만할 수 있는그 아래에서 실행하면 rsyslogd기본적으로 /run/log커널, UDP 로그 입력을 이전 방식으로 관리합니다.반품이를 기록하는 더 많은 "daemontools 기본" 방법이 제공됩니다.

• klogd이 로그 스트림을 읽고 /proc/kmsg단순히 표준 오류에 쓰는 서비스입니다. 이는 이라는 간단한 프로그램을 통해 수행됩니다 klog-read. 연관된 로그 데몬은 표준 입력의 로그 스트림을 /var/log/sv/klogd로그 디렉터리에 제공합니다.
• local-syslog-read(BSD에서) 데이터그램을 읽고 단순히 표준 오류에 로그 스트림을 쓰는 서비스 입니다. 이는 이라는 프로그램에 의해 수행됩니다. 연관된 로그 데몬은 표준 입력의 로그 스트림을 로그 디렉터리에 제공합니다./dev/log/run/logsyslog-read/var/log/sv/local-syslog-read
• udp-syslog-readUDP syslog 포트에서 수신 대기하고, 전송된 내용을 읽고, 표준 오류에 로그 스트림을 기록하는 서비스입니다. 다시 말하지만, 이 프로그램은 입니다 syslog-read. 관련 로그 데몬은 표준 입력의 로그 스트림을 /var/log/sv/udp-syslog-read로그 디렉터리에 제공합니다.
• (BSD에서) local-priv-syslog-read로그 스트림에서 데이터그램을 읽고 /run/logpriv단순히 로그 스트림을 표준 오류에 쓰는 서비스입니다. 다시 말하지만, 이 프로그램은 입니다 syslog-read. 관련 로그 데몬은 표준 입력의 로그 스트림을 /var/log/sv/local-priv-syslog-read로그 디렉터리에 제공합니다.

도구 세트에는 export-to-rsyslog하나 이상의 로그 디렉터리를 모니터링할 수 있는 도구도 함께 제공됩니다(비침해 시스템 사용).로그 커서) RFC 5424 형식의 새 항목을 네트워크를 통해 지정된 RFC 5426 서버로 보냅니다.

로그 관리를 위해 systemd 사용

systemd-journaldsystemd 에는 systemd가 관리하는 서비스로 실행되는 단일 전체 로그 관리자가 있습니다 .

• /dev/kmsg커널 로그 데이터를 읽습니다 .
• /dev/logGNU C 라이브러리 함수 (symlink-symlink) 에서 애플리케이션 로그 데이터를 읽습니다 ./run/systemd/journal/dev-logsyslog()
• systemd가 관리하는 서비스의 로그 데이터를 AF_LOCAL스트림 소켓에서 수신합니다 ./run/systemd/journal/stdout
• AF_LOCAL/run/systemd/journal/socket이는 시스템별 로깅 프로토콜(예: sd_journal_sendv()et al.) 을 사용하는 프로그램의 로그 데이터를 데이터그램 소켓에서 수신합니다 .
• 그것은 그 모든 것을 함께 혼합합니다.
• /run/log/journal/또는 에 있는 시스템 전체 및 사용자별 로그 파일 세트에 기록합니다 /var/log/journal/.
• (클라이언트로서) 데이터그램 AF_LOCAL소켓 에 연결할 수 /run/systemd/journal/syslog있고 syslog로의 전달이 구성되어 있으면 거기에 로그 데이터를 기록합니다.
• 구성된 경우 쓰기 가능한 메커니즘을 사용하여 커널 버퍼에 로그 데이터를 씁니다 /dev/kmsg.
• 구성된 경우 터미널 및 콘솔 장치에도 로그 데이터를 기록합니다.

프로그램이 충돌하거나 서비스가 중지되면 시스템 전체에 나쁜 일이 발생할 수 있습니다.

systemd 자체는 (특정) 서비스의 표준 출력 및 오류가 소켓에 연결되도록 준비합니다 /run/systemd/journal/stdout. 따라서 일반적인 방법으로 표준 오류에 기록하는 데몬은 출력을 로그에 보냅니다.

이는 klogd, syslogd, syslog-ng 및 rsyslogd를 완전히 대체합니다.

이제 이러한 사항은 구체적으로 체계화되어야 합니다. systemd 시스템에서는 가 될 수 없습니다 /dev/log. 대신 다음 두 가지 접근 방식 중 하나를 취합니다.

• /run/systemd/journal/syslog그들은 (기억한다면) systemd-journald연결을 시도하고 로그 데이터를 기록하는 서버 측이 됩니다 . 몇 년 전에는 imuxsock이를 수행하도록 rsyslogd의 입력 방법을 구성할 수 있었습니다.
• 바이너리 로그 형식을 이해하고 로그 파일과 디렉터리에 추가되는 새 항목을 모니터링하는 시스템별 라이브러리를 사용하여 시스템 로그에서 직접 데이터를 읽습니다. 오늘날 사람들은 imjournalrsyslogd의 입력 방법을 구성하여 이 작업을 수행합니다.