Wyobraź sobie, jak wyglądałoby życie, gdyby krytyczna usługa wysiadła kilka minut temu, a ty zostałeś wezwany, aby uratować dzień. Próbujesz zrestartować usługę, ale ona po prostu nie chce się uruchomić. Nie ma żadnych komunikatów o błędach, ale co ważniejsze, nie ma żadnych śladów tego, co robiła, zanim zdecydowała się umrzeć. Sto i jeden przyczyn przebiegają przez twój umysł, i zdajesz sobie sprawę, że nie ma sposobu, aby wiedzieć, w którym kierunku iść. Może by tak zrestartować serwer. Tylko może.
Ten scenariusz jest jednym z wielu, w których logowanie może przyjść ci na ratunek. Zazwyczaj działające oprogramowanie przechowuje w pliku zapis ważnych działań związanych z jego działaniem dla potomności. Wszystko może być przechowywane w pliku dziennika, ponieważ pomaga to programistom i administratorom wiedzieć, co się stało z danym oprogramowaniem po fakcie. Pliki dziennika są również używane przez osoby dbające o bezpieczeństwo do sprawdzania dostępu do poszczególnych zasobów. W przypadku sieci lub wiadomości, pliki dziennika rejestrują czas wysłania lub otrzymania wiadomości w celu późniejszego odniesienia.
Pliki dziennika, z definicji, zwiększają swój rozmiar w zależności od częstotliwości i dosłowności, z jaką są aktualizowane. Aby służyły swojemu celowi, są zwykle otwierane w trybie dołączania i zawierają znaczniki czasu, aby pomóc w rozwiązywaniu problemów i kryminalistyce. Stanowi to jednak problem, ponieważ duże rozmiary plików sprawiają, że praca z plikami dzienników jest uciążliwa zarówno dla systemu, jak i dla człowieka. Dzienniki są rotowane, aby zachować ich stabilność. Mówiąc prościej, nowy plik jest otwierany, podczas gdy starszy jest zamykany i albo zachowywany, albo usuwany w zależności od preferencji projektowych. Zapobiega to zapełnianiu przez dzienniki całych partycji i powalaniu systemów na kolana w tym procesie. Być może zauważyłeś rotację logów w pracy na pobliskim systemie. Spójrz na daty na plikach boot.log.
W tym przypadku, gdy spełniony jest określony warunek, nazwa bieżącego pliku jest zmieniana przez dodanie daty w celu jego identyfikacji i śledzenia, a nowy plik o oryginalnej nazwie jest otwierany, gotowy do odbioru przychodzących komunikatów dziennika.
Logowanie w Linuksie (rsyslogd)
Jak można się spodziewać, logowanie w systemach linuksowych, takich jak serwer CentOS 7, którego używam do ilustracji, opiera się na demonie ułatwiającym logowanie. Rsyslogd to nazwa niezawodnej, starej usługi i jest ona open-source. Właściwie, to nie jest on taki stary. Jest to ulepszona wersja oryginalnego demona syslog i posiada zdolność do szybkiego przetwarzania i przekazywania logów do dowolnej lokalizacji w sieci IP. Oprócz syslog i rsyslog, jest jeszcze syslog-ng, który jest kolejnym demonem do obsługi logów. Domyślny program do obsługi logów zależy od wybranej przez nas dystrybucji. Rsyslog jest domyślnie zainstalowany w wielu dystrybucjach opartych na Red Hat. Uruchom poniższe polecenie, aby sprawdzić jego obecność i wersję w systemie:
rsyslogd -v
Ponieważ jest to demon, można sprawdzić, czy jest aktywny, stosując systemd w następujący sposób:
systemctl status rsyslogd
Jeśli, z jakiegokolwiek powodu nie jest uruchomiony, można go uruchomić poprzez systemd.
Logrotate
Logrotate to narzędzie linuksowe, którego główną funkcją jest – czekajcie na to – rotacja logów. Jeśli nie jest ono zainstalowane jako część domyślnej instalacji systemu operacyjnego, można je zainstalować po prostu uruchamiając:
yum install logrotatePlik binarny można znaleźć pod adresem /bin/logrotate.
Po zainstalowaniu logrotate, nowy plik konfiguracyjny jest umieszczany w katalogu /etc/ w celu kontrolowania ogólnego zachowania narzędzia podczas uruchamiania. Ponadto, tworzony jest folder dla plików konfiguracyjnych snap-in specyficznych dla usługi, aby dostosować żądania rotacji dziennika. Więcej na ten temat nieco później.
Codzienne zadanie cron
Dziennie uruchamiane jest zadanie cron , które uruchamia narzędzie. Osiąga się to przez umieszczenie wywołania narzędzia w standardowym folderze cron dla codziennych zadań. Chociaż specyfika tego wywołania wykracza poza zakres tego artykułu, wystarczy powiedzieć, że jest to po prostu skrypt Bash, który uruchamia binarkę logrotate, mówiąc systemowi, co robić w przypadku błędu.
Standardowa lokalizacja pliku dziennika
Dzienniki w systemie Linux mogą być umieszczone wszędzie tam, gdzie pozwalają na to uprawnienia. Jednak ze względu na fakt, że ich rozmiar i zawartość ciągle się zmieniają, z definicji Hierarchia Systemu Plików nakazuje, aby były one przechowywane w katalogu /var/log/.
Zrzut ekranu poniżej to spojrzenie na zawartość mojego katalogu /var/log.
Pliki konfiguracyjne i przykłady
/etc/logrotate.conf
Pierwszym plikiem, na który należy zwrócić uwagę w odniesieniu do funkcji logrotate jest logrotate.conf. Ten plik konfiguracyjny zawiera dyrektywy dotyczące sposobu, w jaki pliki dziennika mają być domyślnie rotowane. Jeśli nie ma określonego zestawu dyrektyw, narzędzie działa zgodnie z dyrektywami zawartymi w tym pliku.
Poniżej znajduje się przykładowa zawartość pliku konfiguracyjnego.
Przejrzyjmy się kilku dyrektywom, aby poznać elastyczność logrotate. Łaskawie, autor narzędzia umieścił wystarczająco dużo komentarzy, aby nowicjusz mógł zacząć działać. Możesz również zobaczyć stronę man aby się bardziej zagłębić. Dyrektywy weeklydateextcompresscreate, i rotate 4 stwierdzają, że pliki dziennika mają być rotowane co tydzień, że data rotacji powinna być używana jako sufiks identyfikujący rotowane pliki, że rotowane pliki powinny być skompresowane, że nowy plik ma być utworzony do przyjmowania przychodzących logów, i że nie powinno się przechowywać więcej niż cztery logi. Innymi słowy, piąty najnowszy dziennik powinien zostać usunięty. Zauważ również, że w moim systemie, ze względu na obecność # przed dyrektywą compress, kompresja jest domyślnie wyłączona.
Jest też dyrektywa włączająca określony folder: /etc/logrotate.d. Folder ten jest używany dla specyficznych dla pakietu żądań rotacji logów. Pakiety zaprojektowane do korzystania z logrotate upuszczają pliki konfiguracyjne do tego katalogu. Ta modularność jest zgodna z duchem Linuksa i zwiększa rozszerzalność narzędzia. Pliki konfiguracyjne zawierają podobne dyrektywy i niestandardowe pliki logów, gdzie ma to zastosowanie. Możesz również utworzyć własny plik konfiguracyjny do obsługi dowolnego pliku dziennika. Wystarczy nadać mu nazwę, dodać plik dziennika, który ma być przetwarzany i umieścić go w tym katalogu. Wreszcie, istnieją dyrektywy dla plików dziennika bez pakietów właściciela, takich jak wtmp i innych plików dziennika systemowego. Strona man jest wypełniona większą ilością dyrektyw i dla użytkowników, którzy mają bardziej specyficzne potrzeby rotacji, zdecydowanie radzę na nią spojrzeć.
/etc/logrotate.d
Na szczęście, dużo mówiłem na temat katalogu /etc/logrotate.d, więc bez zbędnych ceregieli, pozwólcie, że pokażę wam zawartość tego katalogu, aby przybliżyć wcześniejsze pomysły.
A na wszelki wypadek przyjrzyjmy się plikowi konfiguracyjnemu Samby.
Czy potrafisz zauważyć, jak bardzo jest to podobne do logrotate.conf? Zanim spuszczę zasłonę na ten kawałek, przejrzyjmy kilka dyrektyw w tym pliku:
/var/log/samba/* – Plik dziennika, który ma być rotowany. W tym przypadku jest to każdy plik logu w katalogu logów Samby.
notifempty – Dyrektywa mówiąca, że plik nie powinien być rotowany, jeśli jest pusty.
olddir /var/log/samba/old – Lokalizacja do przechowywania starych rotowanych logów.
missingok – Powstrzymuje logrotate przed wyrzuceniem błędu w przypadku braku pliku logu.
copytruncate – Nie zamykaj pliku logu. Zrób kopię, która będzie obróconym plikiem o zmienionej nazwie, a następnie skróć plik dziennika do zerowego rozmiaru
Czy potrafisz zgadnąć, co robi dyrektywa sharedscripts? Nie musisz zgadywać – zajrzyj na stronę man.
Zawijanie