Blog » DevOps » Linux

Rsyslog część pierwsza – konfiguracja centralnego systemu logów

rsyslog

Niedawno na naszym blogu pojawił się artykuł dotyczący Journald, czyli stosunkowo młodego mechanizmu gromadzenia i zarządzania logami. Dziś przyjrzymy się innemu narzędziu do zbierania logów systemowych – Rsyslog, często błędnie nazywanego Syslogiem.

W tym poradniku omówimy historię, instalację, podstawową konfigurację Rsyslog oraz ustawienia logowania przy pomocy szablonów (ang. template).

O Syslogu słów kilka

Syslog jest protokołem logowania, czyli zespołem zasad dotyczących generowania, formatu i transmisji logów. W swojej pierwszej wersji był on BSD Syslogiem i został opisany przez RFC 3164.

Prawie 8 lat później powstał nowy RFC opisujący de facto standard protokołu Syslog – RFC 5424. Było to związane z szerszą adaptacją oraz koniecznością ustanowienia wspólnej bazy dla programów mających zamiennie móc pełnić funkcje daemonów logów. Pozwala on na wymienność tego typu serwisów, także na zupełnie różnych systemach czy środowiskach.

Jednym z głównych problemów przed powstaniem RFC 5424 było między innymi zdefiniowanie sposobu transportu logów. Przykładowo nadawca i odbiorca mogli mieć inaczej zdefiniowaną kolejność czy całą strukturę wiadomości.

Podstawowe zagadnienia Sysloga

Każdego zainteresowanego dokładniejszym opisem gorąco zachęcam do przeczytania RFC5424. Pozwolę sobie jednak opisać kilka podstawowych zagadnień i myśli przewodnich związanych z Syslogiem:

  • architektura Sysloga została stworzona tak, by móc tworzyć (kreować, budować, formować) dowolną ilość warstw transportu, redundantność odbiorców, przekazicieli i finalnych destynacji logów. Co istotne, zarówno rolę wytwórcy logu (originator), przekaźnika (relay), jak i kolektora (collector) może pełnić ten sam system. Poniżej przedstawiłem dwie przykładowe architektury Sysloga zaczerpnięte prosto z RFC 5424. Mamy tutaj do czynienia z rysunkami tworzonymi przy pomocy znaków ASCII.
+----------+         +---------+
|Originator|---->----|Collector|
|          |-+       +---------+
+----------+  \
               \     +-----+         +---------+
                +->--|Relay|---->----|Collector|
                     +-----+         +---------+

+----------+         +-----+            +---------+
|Originator|---->----|Relay|---->-------|Collector|
|          |-+       +-----+        +---|         |
+----------+  \                    /    +---------+
               \     +-----+      /
                +->--|Relay|-->--/
                     +-----+
  • wiadomość Syslog zawiera informacje ustandaryzowane. Jednak zarówno treść samej wiadomości (loga), jak i informacje dodatkowe są zależne od wytwórcy systemu, serwera czy aplikacji;
  • Syslog nie zapewnia mechanizmu potwierdzenia dostarczenia wiadomości. Na szczęście pośrednio realizuje to stos TCP/IP lub RELP;
  • jedną z najważniejszych składowych jest Severity (ang. dotkliwość) – w kontekście wpływu na zadany system, ważność wiadomości. Wyróżniamy 8 dotkliwości zdarzenia, które może być logowane. 0 oznacza Emergency i z reguły nieużywalność systemu (np. Kernel Panic). Natomiast na drugim końcu skali mamy 7, które odpowiada za wiadomości wspierające proces odpluskwiania (debugowania) programów. Nie bez powodu bardzo podobnie wygląda to w jądrze Linuxa, gdzie logi też posiadają standardowe 8 dotkliwości/ważności. Więcej informacji na ten temat można znaleźć w man 2 syslog;
  • inną często wykorzystywaną składową wiadomości Sysloga jest facility czyli urządzenie/obiekt wysyłający;
    domyślnym formatem zapisu znaków jest UNICODE.

Rsyslog podstawowe informacje

Nazwa Rsyslog jest skrótem rocket-fast system for log processing. Rsyslog może zbierać logi z wielu źródeł, takich jak standardowy Syslog po TCP lub UDP, pliki, logi kernela, logi Journal, RELP (Reliable Event Logging Protocol) czy logi audytu. Jak samo rozwinięcie nazwy wskazuje, Rsyslog został stworzony z myślą o wysokiej wydajności rozwiązania, a dzięki zastosowaniu wielowarstwowej architektury zdefiniowanej przez Syslog można go skalować poziomo.

Inną istotną cechą Rsysloga jest posiadanie dwóch typów dyrektyw konfiguracyjnych. Pierwsze z nich to dyrektywny typu legacy, które zaczynają się od znaku dolara. Drugie to RainerScript. Co oczywiste, nowe wersje dyrektyw są znacząco bardziej potężne (konfigurowalne) od starych. Niestety są one też mniej popularne. Kolejnym faktem, który warto wiedzieć, jest to, iż obiekty definiowane przez obydwa typy reguł nie wpływają na siebie nawzajem.

W artykule tym przedstawimy konfigurację opartą o bardziej uniwersalne i popularne reguły typu legacy.

Rsyslog instalacja

By zainstalować i uruchomić Rsysloga w wersji 8 na EuroLinuxie 7 lub 8, należy wykonać:

sudo yum install -y rsyslog

Następnie można włączyć Rsysloga (enable), czyli zaznaczyć, że powinien on startować wraz z systemem oraz uruchomić jego serwis.

sudo systemctl enable rsyslogd
sudo systemctl start rsyslogd

Ponadto zachęcam także do zainstalowania dokumentacji Rsyslog. Dokumentacja dystrybuowana przez EuroLinuxa nie wymaga obecności pakietu oraz, co z tego wynika, działania Rsyslog. Dzięki temu możemy się nią posługiwać na naszej stacji roboczej, a zmiany wprowadzać do zadanego systemu lub platformy automatyzacji.

By zainstalować pakiety dokumentacji, należy wykonać:

sudo yum install -y rsyslog-doc

Dla EuroLinuxa w wersji 7 dokumentacja znajduje się w katalogu /usr/share/doc/rsyslog-8.24.0/html/, natomiast dla wersji 8 w /usr/share/doc/rsyslog-8.37.0/html/.

Do przeglądania dokumentacji najprościej użyć prawdziwej (niekonsolowej) przeglądarki. Osobiście ze względów wydajnościowych oraz ideologicznych preferuję Firefoxa 🙂 By rozpocząć przygodę z dokumentacją dla EuroLinuxa w wersji 8 (beta), można wykonać:

firefox /usr/share/doc/rsyslog-8.37.0/html/index.html

Analogicznie sprawa wygląda dla wersji 7.

Na koniec tego rozdziału pragnę omówić Rsyslog w innych wersjach Enterprise Linuxa. Otóż EuroLinux w wersji 6 posiada dwie wersje Rsysloga: domyślną jest wersja 5, istnieje jednak pakiet rsyslog7, który, co warto wiedzieć, konfliktuje z domyślnym. W nadchodzącej wersji 8 EuroLinuxa występuje usprawniona (nowsza) 8. wersja Rsysloga.

Konfiguracja z użyciem wzorca

Zanim przejdziemy do konfiguracji Rsysloga, pozwolę sobie na krótki opis środowiska. Wszystkie hosty mają tożsame wpisy w /etc/hosts. W normalnym środowisku należałoby ustawić ich nazwę przy pomocy rozwiązania opartego o serwer DNS. Niemniej na potrzeby prezentacji lub PoC (Proof of Concept) użycie rozwiązywania nazw przy pomocy statycznych wpisów w /etc/hosts jest dopuszczalnym rozwiązaniem.

Plik /etc/hosts zawiera następujące wpisy:

192.168.121.228 logmaster logmaster.example.lab
192.168.121.231 loghost1  loghost1.example.lab
192.168.121.218 loghost2  loghost2.example.lab

W domyślnej konfiguracji Rsyslog zbiera dane z lokalnego systemu i zapisuje je do odpowiednich plików. Plikiem konfiguracyjnym definiującym zachowanie Rsysloga i podejmowane przez niego akcje jest /etc/rsyslog.conf.

W tym artykule stworzymy prosty, centralny serwer logów. By zapisywać osobne pliki logów dla każdego z serwerów, użyjemy szablonu, który ze względu na nazwę logującego komputera będzie zapisywał jego logi do innego pliku.

W tym momencie ponownie zachęcam do zapoznania się z tym, jak wygląda wiadomość wysyłana zgodnie z protokołem Syslog. Specyfikacja tej wiadomości znajduje się w wyżej likowanym RFC5424 na stronie 8. i 9. (na dalszych stronach jest rozwijana). Specyfikacje określa meta język ABNF (Augmented Backus–Naur form).

Interesującym nas polem jest „HOSTNAME”, który może zostać użyty w szablonie. By poznać inne dynamiczne parametry szablonu, polecam zarówno man 5 rsyslog.conf, jak i wcześniej omówioną dokumentację.

Centralny serwer logów

Przejdźmy jednak do konfiguracji centralnego serwera logów. Na samym początku należy włączyć moduł odpowiedzialny za logowanie. Można po prostu odkomentować interesujące nas linijki:

#: diff  /etc/rsyslog.conf.back /etc/rsyslog.conf 
19,20c19,20
< #$ModLoad imtcp
< #$InputTCPServerRun 514
---
> $ModLoad imtcp
> $InputTCPServerRun 514

A następnie dodać szablon:

$template MojSzablon,"/var/log/external/%HOSTNAME%.log"
*.* -?MojSzablon

Szablony mogą przyjmować specjalne parametry, które są wyciągane z wiadomości Sysloga lub innych metadanych. W powyższym przykładzie jest to %HOSTNAME%. Ich dokładny opis znajduje się w manualu man 5 rsyslog.conf oraz w linkowanej dokumentacji przeglądarkowej. Zapis tych parametrów jest bardzo charakterystyczny, gdyż znajdują się one pomiędzy dwoma znakami %. Inne przydatne właściwości wiadomości, które można wykorzystać w szablonie, to między innymi:

  • syslogpriority
  • syslogfacility
  • syslogtag
  • FROMHOST
  • APP-NAME
  • $YEAR
  • $MONTH
  • $DAY
  • $HOUR
  • $MINUTE.

Ich nazwy są samotłumaczące. Osoby zainteresowane mogą znaleźć więcej na ich temat w sekcji PROPERTY REPLACER wspomnianego wcześniej manuala. Warto zwrócić uwagę na APP-NAME, które może zostać wykorzystane do osobnego, bezpiecznego logowania własnych serwisów.

Z kolei druga linijka naszego szablonu tłumaczy się następująco: *.* odpowiada za przekazywanie wszystkich wiadomości, ?MojSzablon wyznacza miejsce logowania zgodnie z szablonem. Ważnym znakiem w konfiguracji jest -, który odpowiada za brak operacji synchronizacji po każdym zebranym zdarzeniu. Opcja ta jest typowym kompromisem. Z jednej strony w przypadku np. nagłej utraty zasilania bez UPS, istnieje możliwość utraty zdarzenia. Z drugiej strony od systemu gromadzącego logi oczekuje się wysokiej wydajności.

Firewalld

Ostatnim krokiem konfiguracyjnym jest ustawienie firewalld (lub iptables w starszych wersjach). Jeśli chcemy pozwolić dowolnemu procesowi pisać do Rsysloga, to wystarczy otworzyć odpowiedni port. Zdarza się jednak, iż logi chcemy zbierać z tylko konkretnych adresów IP. Najprostszym sposobem, by to osiągnąć, są odpowiednie reguły firewalla (mogą być nałożone na sieć lub pojedyncze hosty). Zautomatyzowane dodawanie reguły firewalla przy pomocy odkrytych faktów o systemie opiszę w drugiej części. W tym poradniku natomiast odtworzę port 514 dla całej komunikacji używającej TCP.

$: sudo firewall-cmd --add-port=514/tcp
success
$: sudo firewall-cmd --permanent --add-port=514/tcp
success

Jako że lubię wiedzieć, jak działają pewne mechanizmy, chciałbym zaznaczyć, iż celowo nie użyłem –add-service=syslog ani –add-service=rsyslog. Zarówno firewalld, jak i inne programy tego typu używają pliku /etc/services w celu znalezienia mapowania nazwy serwisu do jego portu. Znajduje się w nim lista portów i odpowiadających im usług. Jest ona zarządzana przez IANA (Internet Assigned Numbers Authority).

Poniżej przedstawiam prosty wyciąg dla portu 514.

$: grep '\W514/' /etc/services
shell           514/tcp         cmd             # no passwords used
syslog          514/udp

Wynika z niego wprost, że użycie serwisu Syslog otworzy nam port 514, ale po UDP W naszym przypadku będzie to niepoprawna konfiguracja. Z kolei serwis Rsyslog, który implementuje (jako jeden z wielu) protokół Syslog, w ogóle nie występuje.

Na sam koniec konfiguracji należy zrestartować usługę Rsyslog:

$: sudo systemctl restart rsyslog

Po przejściu wszystkich powyższych kroków mamy w pełni działający centralny serwer logów.

Konfiguracja rotacji logów

Za rotacje logów w EuroLinuxie w wersji 7 i 8 odpowiada popularne narzędzie logrotate. Jest ono wykonywane raz dziennie, zgodnie ze skryptem umieszczonym w /etc/cron.daily/logrotate. Pakiet Rsyslog zawiera reguły rotacji opracowane dla logrotate. Są one zamieszczone w pliku /etc/logrotate.d/syslog. W związku z tym wystarczy po prostu dopisać odpowiednią ścieżkę lub tzw. globa do istniejących reguł. Przykładowa linijka dodana do ścieżek rotowanych plików definiowanych w /etc/logrotate.d/syslog.

/var/log/external/*log

Jako że logrotate nie jest serwisem, a programem uruchamianym przez crona, nie wymaga on ponownego uruchomienia.

Konfiguracja przesyłania logów

Podstawowa konfiguracja klienta jest dziecinne prosta. Wystarczy bowiem dodać do pliku /etc/rsyslog.conf pojedynczą linijkę:

*.* @@logmaster:514

Ustanawia ona przekazywanie logów protokołem Syslog działającym na TCP/IP do hosta logmaster na port 514. By ustawić przekazywanie logów po UDP, zamiast TCP, należy użyć jednej „@” zamiast dwóch.

Po zmianie konfiguracji należy zrestartować Rsyslog.

sudo systemctl restart rsyslog

Testowanie logowania

Standardowym narzędziem służącym do testowania logowania jest logger. Jest to prosty program wysyłający określoną wiadomość do logów. Wiadomości tej można nadać priorytet, a także określić, z jakiego obiektu pochodzi. Moim ulubionym sposobem jest użycie priorytetu z wartością liczbową (0-7). Do ustawienia priorytetu służy flaga -p.

logger -p 0 "This is emergency from ${HOSTNAME}. Use Bat-Signal."

W ten sposób poinformowaliśmy nasz system o wystąpieniu Emergency, czyli najwyższej (0) ważności zdarzenia. Z reguły oznacza to zatrzymanie systemu i występuje wyjątkowo rzadko. W domyślnej konfiguracji wiadomość ta zostanie wypisana na każdy aktywny w systemie terminal, w tym także na terminal hosta odbierającego logi.

Kolejnym i ostatnim krokiem jest sprawdzenie, czy zgodnie ze wzorcem powstał odpowiedni plik oraz, czy wiadomość rzeczywiście została dostarczona. Posłużymy się w tym celu trywialnym wyrażeniem regularnym:

# grep -i emergency /var/log/external/loghost*
/var/log/external/loghost1.log:Apr 15 14:14:59 loghost1 vagrant: This is emergency from loghost1. Use Bat-Signal.
/var/log/external/loghost2.log:Apr 15 14:15:00 loghost2 vagrant: This is emergency from loghost2. Use Bat-Signal.

Podsumowanie

Zwyczajowo chciałbym podziękować za czas poświęcony na czytanie tego artykułu. Zachęcam też do skonfigurowania swojego serwera kolekcji logów. Oprócz standardowego wykorzystania Rsysloga firma EuroLinux proponuje jeszcze kilka możliwości:

  • wykorzystanie Journald do przekazywania logów do centralnego serwera logów. Jest to jednak temat na osobny artykuł;
  • wykorzystanie platformy EuroLog, która zbiera logi z praktycznie wszystkich logujących urządzeń. Platforma ta oparta jest na znanym i lubianym stosie ELK, do którego oprócz dodatkowych zabezpieczeń, konfiguracji, zapewnienia redundatności oraz wysokiej wydajności firma EuroLinux dodaje także usługę opieki ciągłej. Dzięki temu klient zawsze może skupić się na celach biznesowych, nie przeciążając swoich cennych i trudnodostępnych zasobów ludzkich.

Druga część naszej przygody z konfiguracją Rsysloga przy pomocy Ansible pojawi się w najbliższym czasie 🙂 Poświęcimy ją stworzeniu dwóch ról Ansible konfigurujących odpowiednio: centralny serwer logów i klientów tegoż serwera.

Źródła:
man 2 syslog
man 5 rsyslog.conf
man 8 rsyslogd
Dokumentacja rsyslog
https://tools.ietf.org/html/rfc5424
https://tools.ietf.org/html/rfc3164

Chcesz być na bieżąco? Obserwuj nasz profil w serwisie LinkedIn.

2 komentarzy dla “Rsyslog część pierwsza – konfiguracja centralnego systemu logów

  1. mariano Odpowiedz

    Cześć, napiszę od siebie tylko tyle, że ilekroć szukam wartościowych wpisów w polskim Internecie, często trafiam właśnie na Waszego bloga. To nie jest przypadek. Dzięki!

    • EuroLinux Autor wpisuOdpowiedz

      Dziękujemy za miły komentarz 🙂 Z pewnością na naszym blogu pojawi się jeszcze wiele interesujących treści.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *