Jak rozumiem, jądro Linux loguje się do /proc/kmsgpliku (głównie wiadomości związane ze sprzętem) i /dev/loggniazda? Gdziekolwiek indziej? Czy inne aplikacje mogą również wysyłać wiadomości do /proc/kmsglub /dev/log? Last but not least, mam rację, że jest to demon syslog ( rsyslog , syslog-ng ), który sprawdza wiadomości z tych dwóch miejscach, a następnie rozprowadza tych różnych plików, takich jak /var/log/messageslub /var/log/kern.logczy nawet centralnego serwera syslog?
Odpowiedzi:
Uproszczony, wygląda mniej więcej tak:
Jądro rejestruje komunikaty (za pomocą printk()funkcji) w buforze pierścieniowym w przestrzeni jądra. Te komunikaty są udostępniane aplikacjom przestrzeni użytkownika na dwa sposoby: poprzez /proc/kmsgplik (pod warunkiem, że /procjest zamontowany) i poprzez połączenie sys_syslogsystemowe.
Istnieją dwie główne aplikacje, które czytają (i do pewnego stopnia mogą kontrolować) bufor pierścieniowy jądra: dmesg(1)i klogd(8). Ten pierwszy ma być uruchamiany na żądanie przez użytkowników, aby wydrukować zawartość bufora pierścieniowego. Ten ostatni jest demonem, który odczytuje wiadomości z /proc/kmsg(lub wywołuje sys_syslog, jeśli /procnie jest zamontowany) i wysyła je do syslogd(8)lub do konsoli. To obejmuje stronę jądra.
W przestrzeni użytkownika jest syslogd(8). Jest to demon, który nasłuchuje na wielu gniazdach domeny UNIX (głównie /dev/log, ale inne też można skonfigurować) i opcjonalnie na porcie UDP 514 dla komunikatów. Odbiera również wiadomości od klogd(8)( syslogd(8)nie przejmuje się /proc/kmsg). Następnie zapisuje te wiadomości w niektórych plikach /loglub nazwanych potokach lub wysyła je do niektórych hostów zdalnych (za pośrednictwem syslogprotokołu, na porcie UDP 514), zgodnie z konfiguracją w /etc/syslog.conf.
Aplikacje w przestrzeni użytkownika zwykle używają tej libcfunkcji syslog(3)do rejestrowania wiadomości. libcwysyła te wiadomości do gniazda domeny UNIX /dev/log(gdzie są one czytane syslogd(8)), ale jeśli aplikacja jest chroot(2)ustawiona na -ed, komunikaty mogą zostać zapisane na innych gniazdach, np /var/named/dev/log. do . Jest to oczywiście niezbędne dla aplikacji wysyłających te dzienniki i syslogd(8)uzgodnienia lokalizacji tych gniazd. Z tego powodu syslogd(8)można skonfigurować słuchanie dodatkowych gniazd poza standardem /dev/log.
Wreszcie syslogprotokół jest tylko protokołem datagramowym. Nic nie powstrzymuje aplikacji przed wysyłaniem datagramów syslog do dowolnego gniazda domeny UNIX (pod warunkiem, że jej poświadczenia pozwalają jej otworzyć gniazdo), całkowicie omijając syslog(3)funkcję libc. Jeśli datagramy są poprawnie sformatowane, syslogd(8)możesz użyć ich tak, jakby wiadomości zostały wysłane syslog(3).
Oczywiście powyższe dotyczy tylko „klasycznej” teorii pozyskiwania drewna. Inne demony (takie jak rsyslogi syslog-ng, jak wspomniałeś) mogą zastąpić zwykły syslogd(8)i robić różne fajne rzeczy, takie jak wysyłanie wiadomości do zdalnych hostów za pomocą szyfrowanych połączeń TCP, dostarczanie znaczników czasu wysokiej rozdzielczości i tak dalej. Jest też systemdpowolny fagocytozowanie części systemu UNIX w Linuksie. systemdma własne mechanizmy rejestrowania, ale tę historię musiałby opowiedzieć ktoś inny. :)
Różnice w świecie * BSD:
Na * BSD nie ma klogd(8)i /procalbo nie istnieje (na OpenBSD), albo jest w większości przestarzały (na FreeBSD i NetBSD). syslogd(8)odczytuje komunikaty jądra z urządzenia znakowego /dev/klogi dmesg(1)używa /dev/kmemdo dekodowania nazw jądra. Tylko OpenBSD ma /dev/log. FreeBSD używa dwóch gniazd domeny UNIX /var/run/logi var/rub/logprivzamiast tego, a NetBSD ma /var/run/log.
rsyslognie korzysta z niego, klogd(8)ponieważ jego korzenie sięgają wstecz, a nie dlatego, że ostatnio podjął wyraźną decyzję o jego zlikwidowaniu. Moja pamięć może się jednak zawodzić. W każdym razie, tak jak powiedziałem, starałem się tylko zakryć „klasyczne” rejestrowanie.
rsyslogduruchomionym i jeden Ubuntu 12.04 z syslog-ngdziałającym i oba miały /proc/kmsgotwarty plik zgodnie z lsof, tj. klogdNie był używany. Inną interesującą rzeczą, którą zauważyłem, jest to, że wiadomości dziennika są przechowywane w /proc/kmsgpliku, jeśli nie działa demon syslog i można je przeglądać na przykład za pomocą catedytora tekstowego. Można jednak wyświetlić te wiadomości tylko raz, ponieważ znikają po ich wyświetleniu. Wreszcie, wykonanie dmesgnie powoduje wyczyszczenia zawartości /proc/kmsgpliku.
/proc/kmsgnie jest zwykłym plikiem, nie ma tam niczego „przechowywanego”, jest to tylko widok bufora pierścieniowego jądra. Możesz to przeczytać catwłaśnie dlatego, że nie masz klogd(8)uruchomionego (jeśli uruchomisz klogd(8), cat /proc/kmsgzablokuje). dmesg(1)czyta wiadomości /dev/kmsgzamiast /proc/kmsg; i może również wyczyścić bufor, jeśli to zrobisz.
systemd has its own logging mechanisms, but that story would have to be told by somebody else. :)- Proszę powiedzieć, masz talent :-)
Druga odpowiedź wyjaśnia, jak mówi jej autor, „klasyczne logowanie” w systemie Linux. W dzisiejszych czasach nie działa to w wielu systemach.
Mechanizmy jądra uległy zmianie.
Jądro generuje dane wyjściowe do bufora w pamięci. Oprogramowanie aplikacji może uzyskać do tego dostęp na dwa sposoby. Podsystem rejestrowania zwykle uzyskuje do niego dostęp jako pseudo-FIFO o nazwie /proc/kmsg. Tego źródła informacji dziennika nie można z powodzeniem udostępniać między czytnikami dziennika, ponieważ jest on czytany jeden raz. Jeśli współużytkuje je wiele procesów, każdy z nich otrzymuje tylko część strumienia danych dziennika jądra. Jest także przeznaczony tylko do odczytu.
Innym sposobem uzyskania dostępu jest nowsze /dev/kmsgurządzenie postaci. Jest to interfejs do odczytu i zapisu, który można udostępniać wielu procesom klienckim. Jeśli współużytkuje je wiele procesów, wszystkie odczytują ten sam pełny strumień danych, na które nie mają wpływu. Jeśli otworzą go w celu dostępu do zapisu, mogą również wstrzykiwać wiadomości do strumienia dziennika jądra, tak jakby zostały wygenerowane przez jądro.
/proc/kmsgi /dev/kmsgpodać dane dziennika w formie innej niż RFC-5424.
Aplikacje uległy zmianie.
Funkcja biblioteki GNU C syslog()w głównych próbach połączenia się z AF_LOCALnazwanym gniazdem datagramu /dev/logi zapisania w nim wpisów dziennika. (Funkcja biblioteki BSD C syslog()używa obecnie /var/run/logjako nazwy gniazda i próbuje /var/run/logprivnajpierw.) Aplikacje mogą oczywiście mieć własny kod, aby to zrobić bezpośrednio. Funkcja biblioteki to po prostu kod (do otwierania, łączenia, zapisywania i zamykania gniazda), wykonujący w końcu we własnym kontekście procesu aplikacji.
Aplikacje mogą również wysyłać wiadomości RFC 5424 za pośrednictwem UDP na lokalny serwer RFC 5426, jeśli nasłuchuje na gnieździe AF_INET/ AF_INET6datagramie na komputerze.
Dzięki presji ze strony świata Daemontools w ciągu ostatnich dwóch dziesięcioleci wiele dæmons obsługuje działanie w trybie, w którym nie używają syslog()funkcji biblioteki GNU C ani gniazd UDP, a jedynie wypluwają swoje dane dziennika do standardowego błędu w zwykła moda na Uniksa.
Dzięki rodzinie zestawów narzędzi daemontools rejestrowanie jest bardzo elastyczne. Ale ogólnie rzecz biorąc, w całej rodzinie chodzi o to, że każdy „główny” demon ma powiązany „rejestr”. „główne” dæmons działają podobnie jak procesy inne niż demon i zapisują swoje komunikaty w dzienniku do standardowego błędu (lub standardowego wyjścia), który podsystem zarządzania usługami łączy za pośrednictwem potoku (który utrzymuje otwarte, aby dane dziennika nie zostały utracone restart usługi) na standardowe wejście dæmon „logowania”.
Wszystkie dæmons „logujące” uruchamiają program, który gdzieś loguje . Ogólnie ten program jest coś multiloglub cyclogże czyta ze standardowego wejścia i zapisuje (nanosekundy o czasie,) plików w ściśle size-ograniczona, obracane automatycznie, wyłączny zapisu, katalog zalogować. Ogólnie rzecz biorąc, wszystkie te demony działają pod egidą indywidualnych dedykowanych nieuprzywilejowanych kont użytkowników.
Tak więc powstaje w dużej mierze rozproszony system rejestrowania, w którym dane dziennika każdej usługi są przetwarzane osobno.
Jedno można uruchomić coś podobnego klogdlub syslogdczy rsyslogdpod zarządzania usługami daemontools mieszkaniami. Jednak świat Daemontools zdał sobie sprawę wiele lat temu, że struktura zarządzania usługami z „logowaniem” dæmons nadaje się do robienia rzeczy w prostszy sposób. Nie ma potrzeby łączenia wszystkich strumieni dziennika w jeden gigantyczny mish-mash, analizowania danych dziennika, a następnie przekierowywania strumieni z powrotem do osobnych plików dziennika; a następnie (w niektórych przypadkach) przykręcić z boku niewiarygodny mechanizm zewnętrznego obracania kłody. Struktura rodziny daemontools jako część standardowego zarządzania logami już wykonuje rotację logów, zapis plików logów i separację strumienia.
Ponadto: model ładowania łańcuchowego upuszczania uprawnień z narzędziami wspólnymi dla wszystkich usług oznacza, że programy rejestrujące nie potrzebują uprawnień administratora; a model UCSPI oznacza, że muszą tylko dbać o różnice, takie jak transport strumieniowy w porównaniu z transportem datagramów.
Zestaw narzędzi nosh jest tego przykładem. Podczas gdy można uruchomić rsyslogdpod nim, po wyjęciu z pudełka, i po prostu zarządzać jądrem /run/logi danymi wejściowymi dziennika UDP w stary sposób; to również zapewnia bardziej „daemontools rodzime” sposoby zalogowaniu te rzeczy:
klogdusługa, która czyta z /proc/kmsgi po prostu pisze, że strumień dziennika do standardowego błędu. Odbywa się to za pomocą prostego programu o nazwie klog-read. Powiązany dziennik dæmon przekazuje strumień dziennika ze standardowym wejściem do /var/log/sv/klogdkatalogu dziennika.local-syslog-readusługa, która czyta z datagramy /dev/log( /run/logna BSD) i po prostu pisze, że strumień dziennika do standardowego błędu. Odbywa się to przez program o nazwie syslog-read. Powiązany dziennik dæmon przekazuje strumień dziennika ze standardowym wejściem do /var/log/sv/local-syslog-readkatalogu dziennika.udp-syslog-readusługa nasłuchuje na porcie UDP Syslog, czyta co jest wysyłane do niego i po prostu pisze, że strumień dziennika do standardowego błędu. Ponownie program jest syslog-read. Powiązany dziennik dæmon przekazuje strumień dziennika ze standardowym wejściem do /var/log/sv/udp-syslog-readkatalogu dziennika.local-priv-syslog-readusługa, która odczytuje datagramy /run/logprivi po prostu zapisuje strumień dziennika do standardowego błędu. Ponownie program jest syslog-read. Powiązany dziennik dæmon przekazuje strumień dziennika ze standardowym wejściem do /var/log/sv/local-priv-syslog-readkatalogu dziennika.Zestaw narzędzi zawiera również export-to-rsyslognarzędzie, które może monitorować jeden lub kilka katalogów dziennika (za pomocą systemu nieinwazyjnych kursorów dziennika ) i wysyłać nowe wpisy w formie RFC 5424 przez sieć do wyznaczonego serwera RFC 5426.
Systemd ma jeden monolityczny program zarządzania dziennika systemd-journald. Działa to jako usługa zarządzana przez systemd.
/dev/kmsgdane dziennika jądra./dev/log(symboliczny link /run/systemd/journal/dev-log) do danych dziennika aplikacji z GNU C Library za syslog()funkcją.AF_LOCALgnieździe w strumieniu /run/systemd/journal/stdoutdanych dziennika pochodzących z usług Systemd zarządzane.AF_LOCALgnieździe datagramowym na /run/systemd/journal/socketdanych pochodzących z dziennika programów, które mówią protokół czasopism Systemd specyficzne (tj sd_journal_sendv()et al.)./run/log/journal/lub /var/log/journal/.AF_LOCALgniazdem datagramu /run/systemd/journal/syslog, zapisuje tam dane dziennika, jeśli skonfigurowano przekazywanie do syslog./dev/kmsgmechanizmu zapisu .Złe rzeczy zdarzają się w całym systemie, jeśli ten program ulegnie awarii lub usługa zostanie zatrzymana.
systemd sam organizuje standardowe wyjścia i błędy (niektórych) usług do przyłączenia do /run/systemd/journal/stdoutgniazda. Więc dæmons, którzy logują się do standardowego błędu w normalny sposób, wysyłają swoje dane wyjściowe do dziennika.
To całkowicie zastępuje klogd, syslogd, syslog-ng i rsyslogd.
Wymagane są teraz specyficzne dla systemu. W systemie systemowym nie stają się końcem serwera /dev/log. Zamiast tego przyjmują jedno z dwóch podejść:
/run/systemd/journal/syslog, który (jeśli pamiętasz) systemd-journaldpróbuje połączyć się i zapisać dane dziennika. Kilka lat temu skonfigurowano by w tym imuxsockcelu metodę wprowadzania rsyslogd .imjournalcelu metodę wprowadzania danych rsyslogd .