Jak skonfigurować logrotate

Bezpieczne i przewidywalne zarządzanie plikami dzienników to podstawa zdrowej administracji systemem. Zbyt rozbudowane logi potrafią w krótkim czasie zająć całe wolne miejsce na dysku, zatrzymać usługi, a nawet doprowadzić do niedostępności serwera. Właśnie dlatego administratorzy posługują się narzędziem logrotate, które automatycznie porządkuje, kompresuje, archiwizuje i usuwa stare wpisy. Poniższy tekst prowadzi krok po kroku od zrozumienia idei rotacji, przez budowę konfiguracji i harmonogramu, po praktyczne przykłady i scenariusze produkcyjne. Znajdziesz tu podpowiedzi, jak unikać pułapek, jak testować reguły oraz jak dopasować rozwiązanie do specyfiki popularnych usług i kontenerów.

Rola logrotate w systemach Linux

Logi to w istocie historia życia usług i aplikacji. Gromadzą komunikaty o błędach, ostrzeżenia, informacje diagnostyczne czy ślady działania użytkowników i procesów. W miarę wzrostu ruchu oraz liczby komponentów rośnie również objętość plików dzienników. Brak kontroli nad ich rozmiarem to nie tylko ryzyko zapełnienia partycji, ale także utrudnione analizy i kopie zapasowe. Mechanizm rotacji logów rozwiązuje ten problem poprzez cykliczne zamykanie bieżących plików i rozpoczynanie nowych, a także porządkowanie starszych plików zgodnie z polityką retencji.

Logrotate, działając cyklicznie, wykonuje trzy główne zadania: rozcina bieżący plik na aktywny i archiwalny, nadaje nazwy archiwom (zwykle z sufiksem daty lub numerem), a następnie stosuje reguły takie jak rotacja (ile wersji trzymać), kompresja (jak zmniejszyć rozmiar archiwów) czy retencja (maksymalny czas przechowywania). Efekt jest dwojaki: utrzymujemy kontrolę nad przestrzenią dyskową i równocześnie zachowujemy historyczne dane w formie łatwej do przeszukania i przenoszenia.

Warto zrozumieć, że logrotate sam w sobie nie wie, kiedy aplikacja zamyka i otwiera uchwyty do pliku. W niektórych przypadkach wystarczy utworzyć nowy plik i przenieść stary do archiwum, ale bywa, że proces wciąż zapisuje do wcześniejszego deskryptora. Aby zapobiec utracie wpisów, korzysta się z dyrektyw wymuszających przeładowanie usługi lub z mechanizmów kopiowania i przycinania. O tym, którą metodę wybrać, decydują sposób pisania logów przez aplikację, ryzyko utraty komunikatów i akceptowalna przerwa w zapisie.

Korzyści płynące z poprawnej konfiguracji widać również podczas analizy zdarzeń. Zamiast jednego ogromnego pliku mamy hierarchię krótkich odcinków czasowych. Dzięki temu łatwiej zawęzić zakres, przenieść na inny serwer czy poddać archiwum szyfrowaniu. Dopełnieniem rotacji jest konsekwentna polityka praw dostępu oraz integracja z narzędziami do zbierania i centralizacji logów (np. Elastic, Loki, Splunk). Nawet jeśli finalnie logi trafiają do zewnętrznego systemu, na węzłach końcowych i tak trzeba zadbać o ich lokalny porządek.

Instalacja i podstawy działania

Na większości dystrybucji Linux logrotate jest domyślnie zainstalowany wraz z systemem bazowym lub pakietami narzędziowymi. Jeśli nie, instalacja zwykle sprowadza się do dodania jednego pakietu z repozytoriów. Domyślna konfiguracja umieszcza plik główny w /etc/logrotate.conf oraz katalog z regułami cząstkowymi w /etc/logrotate.d. Idea jest prosta: plik główny definiuje zachowanie globalne i włącza reguły per-usługa znajdujące się w katalogu.

Logrotate działa wsadowo: uruchamiany jest przez harmonogram (o czym szerzej później) i przetwarza wszystkie zdefiniowane reguły. Dla każdego pasującego wzorca sprawdza warunki rotacji, takie jak przekroczony czas czy rozmiar. Jeśli trzeba wykonać rotację, generuje archiwum, kompresuje je, przenosi w docelowe miejsce i w razie potrzeby uruchamia skrypty towarzyszące. Nad stanem czuwa plik statusu (zwykle /var/lib/logrotate/status), w którym zapisany jest ostatni czas rotacji dla poszczególnych pozycji. Dzięki temu rotacje czasowe (np. daily/weekly/monthly) nie są uzależnione wyłącznie od daty mtime pliku.

Przebieg jednej rotacji można streścić następująco: narzędzie sprawdza warunek (np. minął dzień lub rozmiar przekroczył 100M), obraca plik (zmienia nazwę bieżącego, tworzy nowy), wykonuje ewentualne skrypty w sekcjach prerotate/firstaction i postrotate/lastaction, a następnie porządkuje archiwa (usuwa nadmiarowe, kompresuje itp.). Kluczem jest zapewnienie, że usługa pisząca do loga prawidłowo otworzy nowy plik po obrocie. Gdy nie możemy wymusić przeładowania procesu, alternatywą bywa dyrektywa używająca techniki kopiowania.

W praktyce większość pakietów instaluje swoje reguły w /etc/logrotate.d. Znajdziesz tam przykłady dla demona systemowego logowania, serwerów WWW, baz danych czy narzędzi do konteneryzacji. To dobra baza do nauki: można porównać, jak producenci pakietów rozwiązali kwestie przeładowania, uprawnień i kompresji, a następnie dopasować te wzorce do własnych aplikacji.

Struktura plików konfiguracyjnych

Konfiguracja opiera się na prostym języku składającym się z dyrektyw globalnych i bloków przypisanych do plików. Na początku zwykle znajduje się plik /etc/logrotate.conf. To w nim spotkasz globalne ustawienia, takie jak domyślna kompresja, liczba wersji do utrzymania, schemat nazewnictwa czy katalog z regułami cząstkowymi. Klasyczna linia include /etc/logrotate.d sprawia, że każda pozycja w tym katalogu staje się częścią konfiguracji.

Reguły dla konkretnych plików umieszcza się w blokach złożonych z listy ścieżek i pary nawiasów klamrowych. Wewnątrz bloku znajdują się dyrektywy dedykowane tej grupie logów. Można używać wzorców (np. /var/log/nginx/*.log), a także selektywnie nadpisywać wartości globalne. Kolejność ma znaczenie w przypadku dyrektyw akcji – sekcje firstaction i lastaction otaczają właściwą rotację, natomiast prerotate i postrotate uruchamiają skrypty odpowiednio tuż przed i po obrocie.

Ważnym elementem jest plik statusu, często przechowywany w /var/lib/logrotate/logrotate.status (lub w starszych dystrybucjach pod nieco inną nazwą). Przeniesienie lub usunięcie tego pliku może spowodować, że narzędzie uzna, jakoby wszystkie pozycje wymagały natychmiastowej rotacji, co bywa pożądane (np. przy migracji), ale potrafi też zaskoczyć. Dlatego modyfikacje statusu i wymuszanie działania lepiej wykonywać świadomie, używając flag narzędzia, a nie ręcznego kasowania plików.

Dyrektywy globalne są dziedziczone przez bloki, chyba że zostaną w nich nadpisane. Na przykład włączając globalnie kompresję, w pojedynczym bloku można ją wyłączyć. Ten model ułatwia definiowanie spójnych polityk i ich wyjątków, np. krótszej retencji dla logów o małej wartości lub braku kompresji tam, gdzie liczy się szybkie skanowanie plików przez zewnętrzne narzędzia.

Opcje konfiguracji – rotacja, kompresja, retencja

Najczęściej spotykane dyrektywy to te określające częstotliwość i warunki działania. daily, weekly lub monthly wymuszają rotację w interwale czasowym. minsize i size to warunkowanie po rozmiarze – rotacja nastąpi tylko wtedy, gdy plik przekroczy próg (minsize) albo zawsze, gdy osiągnie wskazaną wielkość (size). Możesz je łączyć z interwałami czasowymi, tworząc warunki mieszane. Istnieje też maxsize i maxage, dzięki którym ograniczasz pojedynczy plik lub łączny czas życia archiwów.

Za politykę przechowywania odpowiada rotate N (gdzie N to liczba wersji). W połączeniu z dateext logrotate nadaje archiwom sufiksy dat. Bez tego używa numeracji .1, .2, itd. dateformat umożliwia własny wzorzec nazwy, często przydatny, gdy archiwum trafia do zewnętrznych systemów. olddir pozwala przenieść obrócone pliki do osobnego katalogu, co utrzymuje porządek i ułatwia uprawnienia. Z kolei missingok i notifempty decydują, czy brak lub pusty plik ma być traktowany jako błąd lub pomijany.

W zakresie kompresji najczęściej używa się compress oraz delaycompress. Pierwsza włącza kompresję archiwów, druga odracza ją o jeden cykl, aby nowo obrócony plik nie został natychmiast skompresowany – to ważne, gdy usługa może przez krótki czas nadal pisać do starego pliku. Można też ustawiać compresscmd, uncompresscmd i compressoptions, dobierając inny algorytm (np. xz, zstd) i poziom kompresji. Pamiętaj, że zbyt agresywna kompresja zwiększa obciążenie CPU i wydłuża czas wykonania rotacji.

Uprawnienia i właścicieli nowych plików definiuje dyrektywa create z parametrami trybu oraz użytkownika i grupy (np. create 640 www-data adm). Od wersji 3.8 dostępne jest su user group w bloku, co pozwala wykonywać skrypty w kontekście nie-root, o ile harmonogram uruchamia logrotate z odpowiednimi prawami. To rozwiązanie bywa przydatne na serwerach o restrykcyjnym modelu bezpieczeństwa.

Istotnym wyborem jest sposób przełączenia aplikacji na nowy plik. Idealnie, jeśli usługa reaguje na sygnał lub przeładowanie (reload) i sama zamyka stary deskryptor. Gdy to niemożliwe, można użyć copytruncate, który kopiuje bieżącą zawartość do archiwum i ucina oryginał, pozostawiając ten sam plik dla procesu. Metoda jest prosta i bezpieczna dla aplikacji ignorujących sygnały, ale niesie ryzyko utraty ostatnich bajtów między kopiowaniem a ucięciem. Z tego powodu warto rozważyć ją tylko tam, gdzie nie możemy wykonać przeładowania lub jest ono niepożądane.

Dodatkowe dyrektywy, o których warto pamiętać, to sharedscripts (wykonuje skrypty raz na grupę plików, a nie dla każdego), dateyesterday (oznacza archiwa datą poprzedniego dnia), extension (wymuszenie rozszerzenia dla archiwów), oraz shred/shredcycles (nadpisywanie danych przed usunięciem w środowiskach o wysokich wymogach bezpieczeństwa). Wreszcie, firstaction/lastaction pozwalają otoczyć cały cykl rotacji dodatkowymi czynnościami, np. chwilowym wstrzymaniem kolejkowania logów po stronie proxy.

Harmonogram, uruchamianie i testowanie

Logrotate nie działa stale – wywoływany jest przez system harmonogramu. Na starszych i konserwatywnych dystrybucjach stosuje się cron. Zadanie w /etc/cron.daily uruchamia logrotate raz dziennie, co typowo wystarcza dla reguł daily/weekly/monthly, a także dla rotacji warunkowanych rozmiarem (narzędzie przy każdym przebiegu sprawdza size/minsize). W nowszych systemach proces jest zwykle obsługiwany przez systemd timer (logrotate.timer), co daje lepszą kontrolę okienka czasowego, dziennikowania i zależności usług.

Niezależnie od mechanizmu harmonogramu można wywołać logrotate ręcznie. To cenna technika testowania, szczególnie w środowiskach produkcyjnych, gdzie każda zmiana musi zostać przewidziana. Najczęściej używa się trybu dry-run (flaga -d), trybu wylewnego (-v) oraz wymuszenia rotacji (-f). Pierwszy pokaże planowane działania bez modyfikowania systemu, drugi ułatwi analizę przebiegu, a trzeci pozwoli przeprowadzić rotację nawet wtedy, gdy warunki nie zostały spełnione.

Warto pamiętać o pliku statusu i domyślnej ścieżce konfiguracyjnej. W trybie testowym można korzystać z alternatywnych plików (-s dla statusu, podanie innej ścieżki do configu), co ułatwia tworzenie scenariuszy w bezpiecznym środowisku lub kontenerze. Przykładowy cykl pracy: wprowadź zmianę w /etc/logrotate.d/aplikacja, wykonaj logrotate -d /etc/logrotate.conf, popraw błędy, następnie logrotate -f /etc/logrotate.conf, a na koniec sprawdź efekty w katalogu z logami.

Harmonogram ma znaczenie przy regułach hourly. Można dodać dedykowane zadanie w /etc/cron.hourly lub zdefiniować osobny timer w systemd. Trzeba jednak ocenić wpływ na wydajność: częstsze przebiegi oznaczają częstsze skrypty i potencjalne konflikty z procesami intensywnie zapisującymi logi. Zwykle interwał dzienny jest wystarczający, a interwał godzinny stosuje się w środowiskach o ekstremalnym wolumenie danych.

Konfiguracje dla popularnych usług

Niektóre aplikacje wzorcowo współpracują z rotacją – wystarczy wysłać sygnał USR1 lub wykonać reload, inne wymagają specjalnych kroków. Poniżej kilka scenariuszy, które często pojawiają się w praktyce.

Nginx: typowa reguła obejmuje /var/log/nginx/*.log i wykorzystuje sygnał USR1 do przełączenia deskryptorów. Często spotkasz blok z daily, missingok, rotate 14, compress, delaycompress, notifempty, create 640 www-data adm, sharedscripts oraz sekcją postrotate, która wywołuje kill -USR1 na PID procesu z /run/nginx.pid. Dzięki temu serwer natychmiast zaczyna pisać do nowego pliku, a obrócony log jest bezpieczny do kompresji.
Apache HTTPD: standardowo używa się przeładowania konfiguracji (graceful lub reload), co powoduje zamknięcie i ponowne otwarcie logów. W dystrybucjach Debian/Ubuntu reguła logrotate zazwyczaj korzysta z polecenia systemctl reload apache2 w bloku postrotate. Warto sprawdzić, jaką metodą serwer został skonfigurowany (rotatelogs, piped logs), bo to wpływa na konieczność dodatkowych kroków.
Rsyslog/syslog-ng: reguły dostarczane z pakietami zwykle zawierają sharedscripts i postrotate do zasygnalizowania demonom, że rotacja miała miejsce. To ważne w przypadku plików zbiorczych, do których zapisują procesy systemowe i wiele usług pośrednio.
MariaDB/MySQL: log błędów i dzienniki zapytań mają własną semantykę. Typową praktyką jest wywołanie mysqladmin flush-logs w sekcji postrotate, co powoduje bezpieczne przełączenie. Należy zachować odpowiednie uprawnienia do wywołania polecenia i upewnić się, że ścieżki do logów odpowiadają temu, co zadeklarowano w konfiguracji serwera baz danych.
PostgreSQL: ma natywną rotację wbudowaną (polecenia log_rotation_age, log_rotation_size). W wielu przypadkach lepiej nie stosować logrotate do plików Postgresa, tylko skonfigurować rotację w samym DBMS, aby uniknąć wyścigów po stronie deskryptorów.
systemd-journald: to osobny świat – dziennik binarny zarządzany jest przez journald według parametrów w journald.conf (SystemMaxUse, SystemMaxFileSize, MaxRetentionSec). Nie rotuje się go logrotate, a narzędziem porządkowym jest journalctl (np. journalctl –vacuum-size=1G). Jeśli jednak logi są przekazywane do plików przez rsyslog, wtedy logrotate zarządza właśnie tymi plikami.
Docker i kontenery: domyślny sterownik json-file może generować ogromne pliki w /var/lib/docker/containers/*/*.log. Najlepszą praktyką jest rotacja na poziomie demon.json (log-driver i log-opts), ale jeśli z jakiegoś powodu nie jest to możliwe, można zastosować logrotate ze wzorcem path i dyrektywą copytruncate, mając świadomość potencjalnego ubytku kilku bajtów przy intensywnym zapisie.

W każdym z tych przypadków kluczem jest dopasowanie metody przełączenia: sygnał do usługi, reload lub awaryjnie copytruncate. Odpowiednie uprawnienia nowych plików i właściwa kompresja są równie ważne, aby narzędzia analityczne zachowały dostęp i wydajność.

Najczęstsze błędy i debugowanie

Jeśli rotacja nie działa, zwykle przyczyną jest jedna z kilku klasycznych pułapek. Po pierwsze – zły wzorzec ścieżki. Gdy w katalogu pojawią się symlinki lub nietypowe rozszerzenia, reguła może je pominąć albo niechcący objąć. Warto jawnie wskazywać zakres, unikać zbyt szerokich gwiazdek i korzystać z oddzielnych bloków dla różnych klas plików. Po drugie – brak reakcji aplikacji na rotację. Proces nadal pisze do starego deskryptora, a my kompresujemy plik, który jeszcze rośnie. Rozwiązaniem jest poprawna sekcja postrotate albo zmiana podejścia na copytruncate.

Po trzecie – konflikt praw dostępu. Gdy logrotate tworzy nowy plik z domyślnymi uprawnieniami, a aplikacja wymaga innych, wpisy przestają się pojawiać. Sprawdź dyrektywę create oraz ewentualne su w bloku, by skrypty wykonywały się we właściwym kontekście. Dotyczy to również systemów z aktywną polityką SELinux: po utworzeniu nowego pliku może on mieć niepoprawny kontekst. Dodanie przywracania kontekstu (np. polecenie restorecon w postrotate) bywa konieczne w środowiskach z surową polityką bezpieczeństwa.

Po czwarte – nieświadome skasowanie pliku statusu. Skutkuje to masową rotacją przy kolejnym przebiegu i może zaburzyć harmonogram. Lepiej użyć parametrów -f i -d -v, by kontrolować, co i kiedy zostanie obrócone. Po piąte – zbyt agresywna kompresja lub łańcuch działań w skryptach postrotate trwający zbyt długo. W efekcie kolejne zadanie harmonogramu nakłada się na poprzednie. Pomaga profilowanie, ograniczenie poziomu kompresji oraz używanie sharedscripts, aby uniknąć wielokrotnego wywoływania kosztownych poleceń.

Diagnostyka opiera się na trzech krokach. Najpierw włącz tryb -d, aby zobaczyć planowane działania bez dotykania plików. Następnie włącz -v, by uzyskać szczegółowy przebieg i ewentualne ostrzeżenia. Na koniec użyj -f, aby wymusić rotację konkretnego bloku i sprawdzić, czy skrypty poboczne zadziałają poprawnie. Warto monitorować logi samego systemu (np. /var/log/syslog, /var/log/messages) i dziennik usługi harmonogramu, bo tam często pojawiają się błędy uprawnień lub nieudane komendy z postrotate.

Problemy z nadpisywaniem reguł rozwiązujemy przez porządek w katalogu /etc/logrotate.d i spójność z /etc/logrotate.conf. Gdy dwie reguły obejmują ten sam plik, kolejność może mieć znaczenie. Najlepiej unikać duplikatów i trzymać się jednej reguły na grupę plików. W złożonych środowiskach warto dodać komentarze z uzasadnieniem dyrektyw, co ułatwi późniejsze audyty.

Zaawansowane scenariusze i dobre praktyki

Im większa skala, tym większa potrzeba przewidywalności i automatyzacji. W środowiskach o wielu hostach stosuje się kontrolery konfiguracji (Ansible, Puppet, Salt), aby dystrybuować spójne reguły rotacji. Dobrym zwyczajem jest grupowanie logów według aplikacji i krytyczności, co pozwala przypisywać różne polityki przechowywania i kompresji. Na przykład logi bezpieczeństwa i audytu trzymamy dłużej i z mocniejszym algorytmem kompresji, a logi debug krócej i z mniejszą agresywnością, by ułatwić szybkie przeszukiwanie.

Wielu administratorów z sukcesem stosuje strategię dateext z dateformat oraz olddir, aby oddzielić katalogi z plikami aktywnymi od katalogów archiwalnych. Taki układ ułatwia integrację z narzędziami do backupu: można wykluczyć aktywne pliki z kopii (bo i tak za chwilę się zmienią) i objąć kopią tylko archiwa. W połączeniu z sygnalizowaniem usługom momentu rotacji minimalizujemy okno, w którym dane mogłyby zostać utracone.

Dobre praktyki obejmują też jawne dokumentowanie decyzji. W komentarzach przy regule wyjaśnij, dlaczego zastosowano delaycompress, czemu rotate ma wartość 14, a nie 7, i z jakiego powodu stawiasz na xz zamiast gzip. Taka dokumentacja chroni przed regresją podczas zmian personelu. Dodatkowo, jeśli reguła uruchamia złożone skrypty, rozważ przeniesienie ich do dedykowanych plików shellowych wersjonowanych w repozytorium, a w logrotate umieść tylko minimalny wrapper.

Warto też rozgraniczyć odpowiedzialności: zespoły aplikacyjne powinny dostarczać informację, jak ich procesy reagują na sygnały i czy obsługują reopen log file. Dzięki temu administratorzy systemów unikną nadużywania copytruncate, a aplikacje nie stracą końcowych linii przy intensywnym zapisie. Jeżeli już musisz użyć tej metody, zmniejsz interwał rotacji rozmiarowej (size) i zapewnij delaycompress, aby uniknąć kłopotów z narzędziami skanującymi pliki w czasie rzeczywistym.

Na serwerach z dużą ilością danych opłacalne bywa ustawienie compressoptions na poziom umiarkowany oraz wybór algorytmu lepiej skalującego się wielowątkowo (np. zstd). Jeśli archiwa trafiają do rozwiązania typu object storage, rozważ dateformat, który ułatwia sortowanie i reguły retencji po stronie chmury. Dodatkowo, w środowiskach o wysokich wymaganiach zgodności, dyrektywy shred/shredcycles pomogą spełnić wymogi usuwania nieodwracalnego, choć kosztem czasu wykonania.

Wreszcie, nie zapominaj o monitoringu. Rotacja, która się nie wydarzyła na czas, może zwiastować kłopot. Warto zbierać metryki: rozmiary aktywnych plików, liczbę archiwów, czas trwania postrotate, a także ostrzeżenia o braku uprawnień. Prosty skrypt kontrolny uruchamiany raz dziennie potrafi wyłapać anomalie zanim zapełni się partycja /var. W połączeniu z alertami dyskowymi i obserwacją dzienników harmonogramu tworzy to kompletny obraz kondycji mechanizmu rotacji.

Przykłady i wzorce wdrożeniowe

Poniżej zebrano kilka wzorców, które można adaptować do własnych potrzeb. Zostały opisane słownie, tak aby zwrócić uwagę na sens każdej dyrektywy, a nie jedynie jej składnię.

Serwer WWW z dużym ruchem: reguła dzienna, size 200M, rotate 30, compress, delaycompress, dateext, olddir /var/log/nginx/archive, create 640 www-data adm, sharedscripts, i w postrotate sygnał USR1. Cel: ograniczenie rozmiaru pojedynczej próbki, utrzymanie 30 dni historii i szybkie przełączanie deskryptorów.
Usługa bez obsługi sygnałów: reguła rozmiarowa size 100M, rotate 10, compress, delaycompress, notifempty, copytruncate. Cel: zachować prostotę i zapewnić, że proces nie musi reagować na rotację. Kompromis: możliwa utrata końcowych bajtów przy intensywnym zapisie.
Logi audytowe: reguła tygodniowa, maxage 180, rotate 26, compress z wyższym poziomem, olddir /var/log/audit/archive, shredding na koniec retencji. Cel: spełnienie wymagań zgodności i długie przechowywanie, przy jednoczesnym ograniczeniu kosztu miejsca.
Zbiorczy syslog: reguła dzienna, size 50M, rotate 14, compress, sharedscripts, i postrotate z sygnałem do rsyslog. Cel: zapewnić spójność w rotacji wielu plików jednocześnie, bez wielokrotnego wywoływania ciężkich komend.
Kontekst SELinux: reguła z create 640 root adm, a w postrotate przywrócenie kontekstu poleceniem restorecon na nowo utworzonych plikach. Cel: uniknąć sytuacji, w której aplikacja traci prawo do zapisu po rotacji.

Wzorce te warto testować narzędziem -d i -v, a następnie wdrażać etapami. W środowiskach o krytycznych wymaganiach zauważysz, że najwięcej czasu zajmuje dopieszczenie skryptów postrotate i dobranie właściwych poziomów kompresji. Tu nie ma jednej recepty – potrzebne są pomiary i iteracje.

Podsumowanie i checklista wdrożeniowa

Konfiguracja logrotate to nie jednorazowa czynność, lecz fragment cyklu życia systemu. Gdy zmienia się obciążenie, zmienia się też profil logów i oczekiwania zespołów operacyjnych. Regularny przegląd reguł, testy wymuszonych rotacji oraz monitorowanie skutków (wielkość katalogów, czas wykonania, wpływ na usługi) pozwalają utrzymać stabilność. Poniższa lista kontrolna pomaga przejść od planu do działania.

Zidentyfikuj wszystkie źródła logów i upewnij się, że nie nakładają się reguły z różnych plików w /etc/logrotate.d.
Ustal, jak aplikacje reagują na rotację: sygnał, reload, czy konieczny jest postrotate z poleceniem specyficznym dla usługi.
Wybierz interwał czasowy i/lub progi rozmiaru; połącz je, jeśli to konieczne (np. daily oraz size 100M).
Skonfiguruj kompresję i ewentualne opóźnienie kompresji, aby nie zakłócić aplikacji skanujących świeżo obrócone pliki.
Zadbaj o prawa i właścicieli nowych plików poprzez dyrektywę create, a w środowiskach restrykcyjnych użyj su i przywracania kontekstu bezpieczeństwa.
Jeśli aplikacja nie reaguje na sygnały lub reload, rozważ copytruncate ze świadomą oceną ryzyka utraty końcówki.
Włącz dateext/dateformat i olddir, by uprościć porządkowanie oraz integrację z kopią zapasową i archiwizacją.
Zaplanuj harmonogram i sprawdź, czy rotacją zarządza cron, czy timer w systemd; dopasuj okno uruchamiania do obciążenia.
Przetestuj reguły parametrami -d oraz -v; wdrażaj z -f tylko tam, gdzie jesteś pewien efektu.
Dodaj monitoring: rozmiary aktywnych logów, liczbę archiwów, błędy z przebiegów i czasy wykonania skryptów.

Po przejściu przez powyższe kroki zyskasz kontrolę nad cyklem życia logów, ograniczysz ryzyko awarii wynikającej z zapełnienia dysku, a jednocześnie ułatwisz analizę i archiwizację danych operacyjnych. Największą wartością jest przewidywalność: wiadomo, gdzie są archiwa, jak się nazywają, kto ma do nich dostęp i jak długo pozostają w systemie. Na tym opiera się dojrzała praktyka eksploatacji serwerów i klastrów aplikacyjnych.