📋 Jak używać logrotate do rotacji i archiwizacji logów systemowych w systemie Linux

Pliki logów są kluczowym elementem każdego systemu, dostarczając bezcennych informacji o jego działaniu, błędach i potencjalnych zagrożeniach. Jednak bez odpowiedniego zarządzania, logi mogą szybko rozrosnąć się do gigantycznych rozmiarów, zajmując przestrzeń dyskową i utrudniając analizę. W tym kompleksowym przewodniku poznasz logrotate - potężne narzędzie w systemach Linux, które automatyzuje rotację, kompresję i archiwizację plików logów, zapewniając ich efektywne zarządzanie.

⚡ Ekspresowe Podsumowanie:

  1. Zrozumienie logrotate - poznaj podstawowe zasady działania i lokalizację plików konfiguracyjnych narzędzia.
  2. Konfiguracja rotacji - naucz się ustawiać częstotliwość rotacji, kompresję i retencję logów.
  3. Zaawansowane opcje - wykorzystaj skrypty prerotate/postrotate, warunki i niestandardowe wzorce.
  4. Przykłady praktyczne - gotowe konfiguracje dla popularnych usług i aplikacji.

🗺️ Spis Treści - Twoja Mapa Drogowa

📋 Wprowadzenie do logrotate

Czym jest logrotate i dlaczego jest niezbędny?

Logrotate to standardowe narzędzie w systemach Linux, zaprojektowane do automatycznego zarządzania plikami logów. Jego główne zadania to:

  • Rotacja logów - zamykanie bieżących plików logów i tworzenie nowych
  • Kompresja - zmniejszanie rozmiaru starszych plików logów
  • Archiwizacja - przechowywanie logów przez określony czas
  • Usuwanie - pozbywanie się najstarszych plików logów według zdefiniowanych reguł

Bez odpowiedniego zarządzania, pliki logów mogą:

  • Zajmować nadmierną ilość przestrzeni dyskowej
  • Spowalniać system podczas operacji na dużych plikach
  • Utrudniać analizę i wyszukiwanie informacji
  • W skrajnych przypadkach doprowadzić do zapełnienia dysku i awarii systemu

Jak działa logrotate?

Logrotate działa na podstawie zdefiniowanych reguł, wykonując następujące kroki:

  1. Sprawdzenie czy plik logu spełnia warunki rotacji (rozmiar, czas, itp.)
  2. Jeśli warunki są spełnione:
    • Zamknięcie bieżącego pliku logu
    • Zmiana nazwy pliku zgodnie z konfiguracją (np. dodanie daty)
    • Utworzenie nowego, pustego pliku logu
    • Opcjonalna kompresja starszego pliku
    • Usunięcie najstarszych plików według zdefiniowanych zasad retencji
  3. Wykonanie zdefiniowanych skryptów przed i po rotacji

Domyślnie, logrotate jest uruchamiany codziennie przez zadanie cron:

/etc/cron.daily/logrotate

Lokalizacja plików konfiguracyjnych

Logrotate korzysta z następujących plików konfiguracyjnych:

  • /etc/logrotate.conf - główny plik konfiguracyjny, zawierający globalne ustawienia
  • /etc/logrotate.d/ - katalog zawierający dodatkowe pliki konfiguracyjne, zwykle jeden plik na aplikację lub usługę

Struktura ta pozwala na:

  • Centralne zarządzanie globalnymi ustawieniami
  • Modularną konfigurację specyficzną dla konkretnych usług
  • Łatwą instalację i odinstalowanie konfiguracji wraz z pakietami

✨ Pro Tip: Aby sprawdzić, jak zachowa się logrotate bez faktycznego wykonywania rotacji, użyj opcji -d (debug):

sudo logrotate -d /etc/logrotate.conf

🔧 Podstawowa konfiguracja logrotate

Instalacja logrotate (jeśli nie jest zainstalowany)

W większości dystrybucji Linux, logrotate jest instalowany domyślnie. Jeśli jednak go brakuje, można go łatwo zainstalować:

Dla systemów opartych na Debian/Ubuntu:

sudo apt update
sudo apt install logrotate

Dla systemów opartych na RHEL/CentOS/Fedora:

sudo yum install logrotate
# lub
sudo dnf install logrotate

Struktura pliku konfiguracyjnego

Każdy plik konfiguracyjny logrotate składa się z globalnych dyrektyw i bloków konfiguracyjnych dla konkretnych plików logów:

# Globalne dyrektywy (opcjonalne)
weekly
rotate 4
create
compress
include /etc/logrotate.d

# Blok konfiguracyjny dla konkretnego pliku lub wzorca
/var/log/przykład.log {
    # Dyrektywy specyficzne dla tego pliku
    monthly
    rotate 12
    compress
    missingok
}

Dyrektywy specyficzne dla pliku nadpisują globalne ustawienia.

Najważniejsze opcje konfiguracyjne

Podstawowe dyrektywy czasowe

Dyrektywa Opis
daily Rotacja wykonywana codziennie
weekly Rotacja wykonywana raz w tygodniu
monthly Rotacja wykonywana raz w miesiącu
yearly Rotacja wykonywana raz w roku

Dyrektywy retencji i rozmiaru

Dyrektywa Opis
rotate n Zachowanie n zrotowanych plików przed usunięciem
size size Rotacja, gdy plik przekroczy określony rozmiar (np. 100M, 1G)
maxsize size Maksymalny rozmiar pliku przed rotacją
minsize size Minimalny rozmiar pliku przed rotacją

Dyrektywy kompresji

Dyrektywa Opis
compress Kompresja zrotowanych plików
nocompress Brak kompresji zrotowanych plików
compresscmd Polecenie używane do kompresji (domyślnie gzip)
compressext Rozszerzenie dla skompresowanych plików
delaycompress Opóźnienie kompresji do następnego cyklu rotacji

Dyrektywy obsługi plików

Dyrektywa Opis
create mode owner group Tworzenie nowego pustego pliku z określonymi uprawnieniami
nocreate Brak tworzenia nowego pliku po rotacji
copytruncate Kopiowanie zawartości i wyczyszczenie oryginalnego pliku
notifempty Pominięcie rotacji pustych plików
missingok Brak błędu, jeśli plik nie istnieje
nomissingok Zgłoszenie błędu, jeśli plik nie istnieje

Przykład podstawowej konfiguracji

Oto przykład prostej konfiguracji logrotate dla pliku logu aplikacji:

/var/log/aplikacja.log {
    # Rotacja tygodniowa
    weekly

    # Zachowanie 5 ostatnich zrotowanych plików
    rotate 5

    # Kompresja zrotowanych plików
    compress

    # Opóźnienie kompresji o jeden cykl
    delaycompress

    # Ignorowanie braku pliku
    missingok

    # Pominięcie rotacji, jeśli plik jest pusty
    notifempty

    # Tworzenie nowego pliku z określonymi uprawnieniami
    create 0640 www-data adm
}

✨ Pro Tip: Jeśli chcesz zastosować podobne ustawienia do wielu plików, możesz użyć wzorców globbing:

/var/log/aplikacja/*.log {
    weekly
    rotate 5
    compress
    missingok
}

🛠️ Zaawansowana konfiguracja logrotate

Skrypty prerotate i postrotate

Jedną z najpotężniejszych funkcji logrotate są skrypty wykonywane przed i po rotacji:

/var/log/nginx/*.log {
    daily
    rotate 7
    compress

    # Skrypt wykonywany przed rotacją
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
            run-parts /etc/logrotate.d/httpd-prerotate; \
        fi \
    endscript

    # Skrypt wykonywany po rotacji
    postrotate
        systemctl reload nginx
    endscript
}

Typowe zastosowania skryptów:

  • Przeładowanie usługi, aby zaczęła zapisywać do nowego pliku logu
  • Wysyłanie powiadomień o rotacji
  • Kopiowanie logów do zewnętrznego systemu archiwizacji
  • Wykonywanie analiz lub przetwarzania zamkniętych plików

Warunki i wyrażenia logiczne

Logrotate pozwala na użycie warunków do określenia, czy rotacja powinna być wykonana:

/var/log/aplikacja.log {
    # Rotacja, gdy plik przekroczy 100MB lub co tydzień (co nastąpi pierwsze)
    size 100M
    weekly

    # Rotacja tylko jeśli plik jest większy niż 1KB
    minsize 1k

    # Maksymalny rozmiar przed wymuszeniem rotacji
    maxsize 200M

    rotate 5
    compress
}

Datestamp i niestandardowe nazewnictwo

Domyślnie, logrotate dodaje przyrostek numeryczny do zrotowanych plików (np. log.1, log.2.gz). Można to zmienić, używając opcji dateext:

/var/log/aplikacja.log {
    daily
    rotate 30
    compress

    # Dodanie daty zamiast licznika
    dateext

    # Format daty: YYYYMMDD
    dateformat -%Y%m%d

    # Opcjonalnie: własny format
    # dateformat -%Y-%m-%d-%H%M%S
}

Rezultatem będą pliki jak aplikacja.log-20250429.gz.

Konfiguracja dla wielu hostów

Przy zarządzaniu wieloma serwerami, warto standaryzować konfigurację logrotate:

/var/log/remote/%hostname%/*.log {
    daily
    rotate 14
    compress
    missingok
    dateext
    dateformat -%Y%m%d-%H%M%S
    maxage 90
}

Zmienna %hostname% zostanie zastąpiona nazwą hosta, co pozwala na organizację logów według serwerów.

Obsługa aplikacji niekompatybilnych z standardową rotacją

Niektóre aplikacje nie radzą sobie dobrze ze standardową rotacją plików. W takich przypadkach można użyć opcji copytruncate:

/var/log/problematyczna-aplikacja.log {
    daily
    rotate 7
    compress
    missingok

    # Kopiowanie pliku i czyszczenie oryginału zamiast przenoszenia
    copytruncate
}

Uwaga: Przy użyciu copytruncate istnieje niewielkie ryzyko utraty danych zapisywanych dokładnie w momencie rotacji. Jest to kompromis dla aplikacji, które nie mogą być przeładowane.

📊 Przykłady konfiguracji dla popularnych usług

Apache HTTP Server

/var/log/apache2/*.log {
    daily
    rotate 14
    compress
    delaycompress
    notifempty
    create 640 www-data adm
    sharedscripts
    postrotate
        if systemctl status apache2 >/dev/null 2>&1; then \
            systemctl reload apache2; \
        fi
    endscript
}

Nginx

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
            run-parts /etc/logrotate.d/httpd-prerotate; \
        fi
    endscript
    postrotate
        systemctl reload nginx
    endscript
}

MySQL/MariaDB

/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/error.log {
    daily
    rotate 7
    missingok
    create 640 mysql adm
    compress
    sharedscripts
    postrotate
        systemctl reload mysql
    endscript
}

System syslog (rsyslog)

/var/log/syslog {
    daily
    rotate 7
    compress
    delaycompress
    postrotate
        systemctl restart rsyslog
    endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages {
    weekly
    rotate 4
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        systemctl restart rsyslog
    endscript
}

Dzienniki jądra (dmesg)

/var/log/dmesg {
    monthly
    create 640 root adm
    rotate 4
    compress
    delaycompress
    notifempty
    missingok
}

Logi aplikacji kontenera Docker

/var/lib/docker/containers/*/*.log {
    daily
    rotate 7
    compress
    size 50M
    missingok
    delaycompress
    copytruncate
}

✨ Pro Tip: Dla Dockera lepszym rozwiązaniem może być skonfigurowanie sterownika logowania Docker (np. json-file z opcjami rotacji lub przekazywanie logów do zewnętrznego systemu jak syslog).

🔍 Testowanie i rozwiązywanie problemów

Testowanie konfiguracji bez wykonywania rotacji

Przed wdrożeniem zmian w konfiguracji, warto przetestować, jak będzie zachowywać się logrotate:

# Test globalnej konfiguracji
sudo logrotate -d /etc/logrotate.conf

# Test konkretnego pliku konfiguracyjnego
sudo logrotate -d /etc/logrotate.d/nginx

Opcja -d (debug) pokazuje, co logrotate zrobiłby, ale bez faktycznego wykonywania zmian.

Wymuszenie rotacji (niezależnie od harmonogramu)

Aby wymusić rotację, niezależnie od ustalonych warunków:

# Wymuszenie rotacji wszystkich logów
sudo logrotate -f /etc/logrotate.conf

# Wymuszenie rotacji konkretnej konfiguracji
sudo logrotate -f /etc/logrotate.d/aplikacja

Rozwiązywanie typowych problemów

Problem: Logi nie są rotowane pomimo spełnienia warunków

Możliwe przyczyny i rozwiązania:

  • Sprawdź uprawnienia plików logów i konfiguracji
  • Upewnij się, że zadanie cron jest aktywne: ls -l /etc/cron.daily/logrotate
  • Zweryfikuj ścieżki do plików logów (użyj pełnych ścieżek)
  • Sprawdź stan w pliku stanu: cat /var/lib/logrotate/status

Problem: Błędy podczas wykonywania skryptów postrotate

Możliwe przyczyny i rozwiązania:

  • Sprawdź składnię skryptów
  • Upewnij się, że masz odpowiednie uprawnienia
  • Dodaj obsługę błędów w skryptach
  • Sprawdź dziennik systemowy pod kątem błędów: journalctl | grep logrotate

Problem: Aplikacja nadal zapisuje do starego pliku logu

Możliwe przyczyny i rozwiązania:

  • Użyj opcji copytruncate zamiast domyślnej rotacji
  • Upewnij się, że postrotate odpowiednio przeładowuje aplikację
  • Sprawdź, czy aplikacja wymaga sygnału do ponownego otwarcia plików logów

Monitoring i automatyzacja

Dla większych środowisk warto rozważyć monitoring procesu rotacji logów:

  1. Automatyczne powiadomienia:

    # W skrypcie postrotate
if [ $? -ne 0 ]; then
    echo "Błąd rotacji logów" | mail -s "Logrotate Error" admin@example.com
fi

  2. Monitorowanie rozmiaru katalogów z logami:

    # Skrypt do monitorowania
log_size=$(du -sm /var/log | cut -f1)
if [ $log_size -gt 10000 ]; then
    echo "Katalog /var/log przekroczył 10GB" | mail -s "Log Directory Warning" admin@example.com
fi

  3. Integracja z systemami monitoringu jak Nagios, Zabbix czy Prometheus

✨ Pro Tip: Rozważ użycie dedykowanych narzędzi do centralnego zbierania i analizy logów, jak Elasticsearch + Logstash + Kibana (ELK) lub Graylog, które mogą uzupełniać lokalną rotację logów.

💡 Najlepsze praktyki i optymalizacja

Strategia retencji logów

Dobrze zaprojektowana strategia retencji powinna uwzględniać:

  1. Wymagania prawne i zgodność z przepisami

    • Niektóre branże wymagają przechowywania logów przez określony czas
    • RODO/GDPR może wpływać na okres przechowywania danych osobowych

  2. Wartość operacyjną logów

    • Logi błędów: dłuższy okres przechowywania (np. 30-90 dni)
    • Logi dostępu: krótszy okres (np. 7-14 dni)
    • Logi debugowania: bardzo krótki okres (np. 1-3 dni)

  3. Dostępne zasoby

    • Przestrzeń dyskowa
    • Wydajność systemu podczas kompresji

Przykładowa zróżnicowana konfiguracja:

# Krytyczne logi błędów - długa retencja
/var/log/critical/*.log {
    daily
    rotate 90
    compress
}

# Standardowe logi - średnia retencja
/var/log/standard/*.log {
    daily
    rotate 14
    compress
}

# Logi debugowania - krótka retencja
/var/log/debug/*.log {
    daily
    rotate 3
    compress
}

Optymalizacja kompresji

Wybór metody kompresji wpływa na rozmiar plików i obciążenie systemu:

Metoda Współczynnik kompresji Obciążenie CPU Konfiguracja
gzip (domyślna) Średni Niskie compress
bzip2 Wysoki Średnie compresscmd /usr/bin/bzip2
compressext .bz2
xz Bardzo wysoki Wysokie compresscmd /usr/bin/xz
compressext .xz
zstd Wysoki Bardzo niskie compresscmd /usr/bin/zstd
compressext .zst

Dla serwerów o dużym obciążeniu, zstd jest dobrym kompromisem między stopniem kompresji a obciążeniem procesora.

Rotacja oparta na czasie vs. rozmiarze

Strategia Zalety Wady
Oparta na czasie (daily, weekly) • Przewidywalna
• Zgodna z okresami raportowania
• Dobra dla analizy trendów		 • Może powodować bardzo duże pliki
• Ryzyko zapełnienia dysku przy nagłym wzroście logów
Oparta na rozmiarze (size) • Kontrola nad rozmiarem plików
• Ochrona przed zapełnieniem dysku
• Bardziej równomierne pliki		 • Nieprzewidywalna częstotliwość
• Trudniejsza korelacja z czasem
• Może powodować zbyt częste rotacje
Hybrydowa (oba warunki) • Najlepsza kontrola
• Elastyczność
• Bezpieczeństwo		 • Bardziej złożona konfiguracja
• Trudniejsza do zrozumienia

Przykład konfiguracji hybrydowej:

/var/log/aplikacja.log {
    # Rotacja dzienna...
    daily

    # ...ale również gdy plik przekroczy 100MB
    maxsize 100M

    # ...i nie rotuj, jeśli plik jest mniejszy niż 1MB
    minsize 1M

    rotate 14
    compress
}

✅ Checklista optymalizacji logrotate:

  • 🔍 Dostosuj częstotliwość rotacji do tempa generowania logów
  • 🔄 Zróżnicuj okres retencji w zależności od ważności logów
  • 🔒 Ustaw odpowiednie uprawnienia dla nowych plików logów
  • 📱 Dodaj powiadomienia o błędach rotacji
  • 🛡️ Używaj sharedscripts dla wspólnych skryptów postrotate
  • 📊 Monitoruj rozmiar katalogów z logami
  • 🕸️ Rozważ archiwizację najważniejszych logów w zewnętrznym systemie
  • 🚀 Optymalizuj kompresję dla równowagi między rozmiarem a wydajnością

❓ FAQ - Odpowiedzi na Twoje Pytania

Czy logrotate automatycznie usuwa stare logi?
Tak, dzięki dyrektywie rotate n, gdzie n oznacza liczbę zrotowanych plików do zachowania. Po przekroczeniu tej liczby, najstarsze pliki są usuwane. Alternatywnie, można użyć maxage n do usuwania plików starszych niż n dni.

Jak mogę rotować logi aplikacji, która stale trzyma otwarty plik logu?
Dla takich aplikacji najlepiej użyć opcji copytruncate, która kopiuje zawartość pliku, a następnie czyści oryginał, zamiast go przenosić. Należy pamiętać, że istnieje niewielkie ryzyko utraty danych zapisywanych dokładnie w momencie rotacji.

Czy mogę używać logrotate dla aplikacji działających w kontenerach Docker?
Tak, ale wymaga to dodatkowej konfiguracji. Możesz:

  1. Skonfigurować logrotate wewnątrz kontenera
  2. Zamontować logi jako wolumen i rotować je na hoście
  3. Użyć wbudowanych mechanizmów rotacji sterownika logowania Docker (json-file z opcjami)
  4. Przekierować logi do zewnętrznego systemu (np. syslog, fluentd)

Jak często wykonywany jest logrotate?
Domyślnie logrotate jest uruchamiany codziennie przez zadanie cron w /etc/cron.daily/. Można to zmienić, przenosząc skrypt do innego katalogu cron lub tworząc własne zadanie crontab z inną częstotliwością.

Co się stanie, jeśli dysk zapełni się przed zaplanowaną rotacją?
Logrotate sam w sobie nie monitoruje zapełnienia dysku. Aby zabezpieczyć się przed taką sytuacją, można:

  1. Użyć opcji size lub maxsize do rotacji opartej na rozmiarze pliku
  2. Skonfigurować monitoring dysku z automatycznymi akcjami
  3. Użyć systemd do automatycznego uruchamiania logrotate przy wysokim zapełnieniu dysku

🏁 Podsumowanie - Efektywne zarządzanie logami

Poprawnie skonfigurowany logrotate jest niezbędnym elementem zarządzania serwerem Linux, zapewniając:

  1. Kontrolę nad rozmiarem plików logów - zapobieganie zapełnieniu dysku
  2. Organizację historycznych logów - ułatwienie wyszukiwania i analizy
  3. Automatyzację rutynowych zadań - oszczędność czasu administratora
  4. Zgodność z wymogami retencji danych - spełnienie wymagań prawnych i firmowych

Pamiętaj, że efektywne zarządzanie logami to nie tylko ich rotacja, ale cały ekosystem praktyk:

  • Odpowiednia konfiguracja poziomów logowania aplikacji
  • Regularna analiza logów
  • Monitorowanie pod kątem błędów i zagrożeń bezpieczeństwa
  • Centralizacja logów w większych środowiskach

Inwestycja czasu w prawidłową konfigurację logrotate zwraca się wielokrotnie, oszczędzając czas przy rozwiązywaniu problemów, unikaniu awarii związanych z zapełnionym dyskiem i zapewniając dostęp do historycznych danych, gdy są potrzebne.

🚀 Potrzebujesz profesjonalnego hostingu z zarządzanymi serwerami Linux?

Sprawdź ofertę hostingu w IQHost

W IQHost oferujemy w pełni zarządzane serwery z optymalnie skonfigurowaną rotacją logów, monitoringiem i alertami. Nasz zespół ekspertów dba o bezpieczeństwo i wydajność, dzięki czemu możesz skupić się na swoim biznesie, a nie na administracji serwerem.

Kategorie i tagi

Linux Administracja Bezpieczeństwo

Czy ten artykuł był pomocny?

Wróć do listy wpisów

Twoja strona WordPress działa wolno?

Sprawdź nasz hosting WordPress z ultraszybkimi dyskami NVMe i konfiguracją serwera zoptymalizowaną pod kątem wydajności. Doświadcz różnicy już dziś!

Sprawdź ofertę hostingu
30-dniowa gwarancja zwrotu pieniędzy