aby administrator systemu mógł zidentyfikować lub rozwiązać problem w systemie serwerowym CentOS 7 lub RHEL 7, musi znać i przeglądać zdarzenia, które miały miejsce w systemie w określonym czasie z plików dziennika przechowywanych w systemie w katalogu/var / log.
serwer syslog na komputerze z systemem Linux może działać jako centralny punkt monitorowania w sieci, w którym wszystkie serwery, urządzenia sieciowe, routery, przełączniki i większość ich wewnętrznych usług generujących dzienniki, niezależnie od tego, czy są one związane z konkretnym problemem wewnętrznym, czy tylko wiadomościami informacyjnymi, mogą wysyłać swoje dzienniki.
w systemie CentOS / RHEL 7, Demon rsyslog jest preinstalowanym głównym serwerem dziennika, a następnie demonem dziennika systemd (journald).
serwer Rsyslog w kompilacji jako usługa architektury klient / serwer i może osiągnąć obie role jednocześnie. Może działać jako serwer i zbierać wszystkie logi przesyłane przez inne urządzenia w sieci lub może działać jako klient, wysyłając wszystkie wewnętrzne zdarzenia systemowe rejestrowane do zdalnego serwera syslog punktu końcowego.
gdy rsyslog jest skonfigurowany jako klient, logi mogą być przechowywane lokalnie w plikach na lokalnym systemie plików lub mogą być wysyłane zdalnie zamiast zapisywać je w plikach przechowywanych na komputerze lub zapisywać pliki dziennika zdarzeń lokalnie i wysyłać je do zdalnego serwera syslog w tym samym czasie.
serwer syslog obsługuje dowolną wiadomość dziennika, używając następującego schematu:
type (facility).priority (severity) destination(where to send the log)
A. Dane obiektu lub typu są reprezentowane przez wewnętrzne procesy systemowe, które generują komunikaty. W Linuksie procesy wewnętrzne (obiekty) generujące logi są standaryzowane w następujący sposób:
- auth = wiadomości generowane przez procesy uwierzytelniania (login).
- cron= komunikaty generowane przez zaplanowane procesy (crontab).
- daemon = wiadomości generowane przez demony (usługi wewnętrzne).
- Kernel = komunikaty generowane przez samo jądro Linuksa.
- mail = wiadomości generowane przez serwer pocztowy.
- syslog = wiadomości generowane przez samego demona rsyslog.
- LPR = komunikaty generowane przez lokalne drukarki lub serwer wydruku.
- local0-local7 = niestandardowe wiadomości zdefiniowane przez administratora (local7 jest zwykle przypisane do Cisco lub Windows).
B. poziomy priorytetu (dotkliwości) są również standaryzowane. Każdy priorytet jest przypisany standardowym skrótem i numerem, jak opisano poniżej. 7. priorytetem jest wyższy poziom wszystkich.
- emerg = Emergency – 0
- alert = Alerts – 1
- err = Errors – 3
- warn = warning – 4
- notice = Notification – 5
- info = Information – 6
- debug = debugowanie– 7
specjalne słowa kluczowe Rsyslog:
- * = wszystkie obiekty lub priorytety
- brak = obiekty nie mają podanych priorytetów np: mail.brak
C. trzecia część schematu syslog jest reprezentowana przez dyrektywę destination. Demon Rsyslog może wysyłać wiadomości dziennika, które mają być zapisane w pliku w lokalnym systemie plików (najczęściej w pliku w katalogu/var/ log/) lub być przesłane do innego lokalnego procesu lub wysłane do lokalnej konsoli użytkownika (na standardowe wyjście), lub wysłać wiadomość do zdalnego serwera syslog poprzez protokół TCP /UDP, lub nawet odrzucić wiadomość do/dev / null.
aby skonfigurować CentOS/RHEL 7 jako centralny serwer dziennika, najpierw musimy sprawdzić i upewnić się, że partycja /var, na której zapisywane są wszystkie pliki dziennika, jest wystarczająco duża (minimum kilka GB), aby móc przechowywać wszystkie pliki dziennika, które będą wysyłane przez inne urządzenia. Dobrym rozwiązaniem jest użycie oddzielnego dysku (LVM, RAID) do zamontowania katalogu /var/log/.
wymagania
- procedura instalacji CentOS 7.3
- procedura instalacji RHEL 7.3
jak skonfigurować Rsyslog na serwerze CentOS/RHEL 7
1. Domyślnie usługa Rsyslog jest instalowana automatycznie i powinna być uruchomiona w CentOS / RHEL 7. Aby sprawdzić, czy demon jest uruchomiony w systemie, wydaj następujące polecenie z uprawnieniami roota.
# systemctl status rsyslog.service
jeśli usługa nie jest domyślnie uruchomiona, wykonaj poniższe polecenie, aby uruchomić demona rsyslog.
# systemctl start rsyslog.service
2. Jeśli pakiet rsyslog nie jest zainstalowany w systemie, którego zamierzasz używać jako scentralizowanego serwera rejestrowania, wydaj następujące polecenie, aby zainstalować pakiet rsyslog.
# yum install rsyslog
3. Pierwszym krokiem, który musimy zrobić w systemie, aby skonfigurować demona rsyslog jako scentralizowany serwer dziennika, aby mógł odbierać wiadomości dziennika dla klientów zewnętrznych, jest otwarcie i edycja, za pomocą ulubionego edytora tekstu, głównego pliku konfiguracyjnego z /etc/rsyslog.conf, jak przedstawiono w poniższym fragmencie.
# vi /etc/rsyslog.conf
w głównym pliku konfiguracyjnym rsyslog Wyszukaj i rozpakuj następujące linie (Usuń znak hashtag # na początku linii), aby zapewnić odbiór transportu UDP do serwera rsyslog przez port 514. UDP jest standardowym protokołem używanym do transmisji logów przez Rsyslog.
$ModLoad imudp $UDPServerRun 514
4. Protokół UDP nie ma narzutu TCP, co czyni go szybszym do przesyłania danych niż protokół TCP. Z drugiej strony protokół UDP nie zapewnia niezawodności przesyłanych danych.
jednak, jeśli chcesz użyć protokołu TCP do odbioru dziennika, musisz wyszukać i rozpakować następujące linie z /etc/rsyslog.plik conf w celu skonfigurowania demona Rsyslog do bindowania i nasłuchiwania gniazda TCP na porcie 514. Gniazda nasłuchowe TCP i UDP do odbioru mogą być konfigurowane jednocześnie na serwerze Rsyslog.
$ModLoad imtcp $InputTCPServerRun 514
5. W następnym kroku nie zamykaj jeszcze pliku, utwórz nowy szablon, który będzie używany do odbierania zdalnych wiadomości. Ten szablon poinstruuje lokalny serwer Rsyslog, gdzie zapisać odebrane wiadomości wysyłane przez klientów sieciowych syslog. Wzór należy dodać przed rozpoczęciem bloku dyrektyw globalnych, jak pokazano w poniższym fragmencie.
$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" . ?RemoteLogs & ~
powyższa dyrektywa $template RemoteLogs instruuje demona Rsyslog, aby zbierał i zapisywał wszystkie odebrane wiadomości dziennika do odrębnych plików, w oparciu o nazwę maszyny klienckiej i zdalny obiekt klienta (aplikację), który generował wiadomości na podstawie zdefiniowanych właściwości prezentowanych w konfiguracji szablonu: %HOSTNAME% i %PROGRAMNAME%.
wszystkie te pliki dziennika będą zapisywane na lokalnym systemie plików do dedykowanego pliku nazwanego po nazwie hosta maszyny klienta i przechowywane w katalogu /var/log/.
reguła & ~ redirect nakazuje lokalnemu serwerowi rsyslog zatrzymanie dalszego przetwarzania odebranej wiadomości dziennika i odrzucenie wiadomości (nie zapisywanie ich do wewnętrznych plików dziennika).
nazwa RemoteLogs jest dowolną nazwą nadaną tej dyrektywie szablonu. Możesz użyć dowolnej nazwy, która najlepiej pasuje do Twojego szablonu.
aby zapisać wszystkie odebrane wiadomości od klientów w jednym pliku dziennika nazwanym po adresie IP zdalnego klienta, bez filtrowania obiektu, który wygenerował wiadomość, użyj poniższego fragmentu.
$template FromIp,"/var/log/%FROMHOST-IP%.log" . ?FromIp & ~
kolejny przykład szablonu, w którym wszystkie wiadomości z flagą AUTH facility będą logowane do szablonu o nazwie „TmplAuth”.
$template TmplAuth, "/var/log/%HOSTNAME%/%PROGRAMNAME%.log" authpriv.* ?TmplAuth
Poniżej znajduje się fragment definicji szablonu z serwera Rsyslog 7:
template(name="TmplMsg" type="string" string="/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log" )
powyższy fragment szablonu można również zapisać jako:
template(name="TmplMsg" type="list") { constant(value="/var/log/remote/msg/") property(name="hostname") constant(value="/") property(name="programname" SecurePath="replace") constant(value=".log") }
aby napisać złożone szablony Rsyslog, przeczytaj instrukcję pliku konfiguracyjnego rsyslog, wydając man rsyslog.polecenie conf lub zapoznaj się z dokumentacją Online Rsyslog.
6. Po edycji pliku konfiguracyjnego Rsyslog z własnymi ustawieniami, jak wyjaśniono powyżej, Uruchom ponownie demona rsyslog w celu zastosowania zmian, wydając następujące polecenie:
# service rsyslog restart
7. Do tej pory Serwer Rsyslog powinien być skonfigurowany tak, aby działał scentralizowany serwer logów i nagrywał wiadomości Od Klientów syslog. Aby zweryfikować gniazda sieciowe Rsyslog, uruchom polecenie netstat z uprawnieniami roota i użyj grep do filtrowania ciągu rsyslog.
# netstat -tulpn | grep rsyslog
8. Jeśli masz włączony SELinux w CentOS / RHEL 7, wydaj następujące polecenie, aby skonfigurować SELinux tak, aby zezwalał na ruch rsyslog w zależności od typu gniazda sieciowego.
# semanage -a -t syslogd_port_t -p udp 514# semanage -a -t syslogd_port_t -p tcp 514
9. Jeśli firewall jest włączony i aktywny, uruchom poniższe polecenie w celu dodania niezbędnych reguł otwierania portów rsyslog w Firewalld.
# firewall-cmd --permanent --add-port=514/tcp# firewall-cmd --permanent --add-port=514/udp# firewall-cmd –reload
to wszystko! Rsyslog jest teraz skonfigurowany w trybie serwera i może centralizować dzienniki ze zdalnych klientów. W następnym artykule zobaczymy, jak skonfigurować klienta rsyslog na serwerze CentOS / RHEL 7.
korzystając z serwera Rsyslog jako centralnego punktu monitorowania zdalnych wiadomości dziennika, możesz sprawdzać pliki dzienników i obserwować stan zdrowia klientów lub łatwiej debugować problemy klienta, gdy systemy ulegają awarii lub są pod jakimś atakiem.