rsyslog z logrotate: przeładuj rsyslog vs copytruncate

Pracuję na Ubuntu 14 z domyślnym narzędziem rsyslog i logrotate.

W domyślnej /etc/logrotate.d/rsyslogkonfiguracji logrotate rsyslog widzę:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

Z tego, co rozumiem, zaleca się stosowanie copytruncate we wszystkich scenariuszach logrotate, ponieważ nie przenosi on bieżącego dziennika, ale raczej obcina dziennik, aby każdy proces z otwartym programem obsługi plików mógł nadal do niego pisać.

Skąd więc domyślna konfiguracja korzystająca z funkcji przeładowywania rsyslog?

Aby odpowiedzieć na twoje pytanie, najpierw musisz zrozumieć inny kompromis przeładowania i copytruncate:

• reload : nazwa starego pliku dziennika zostaje zmieniona, a proces zapisujący ten dziennik jest powiadamiany (za pośrednictwem sygnału Unix) o ponownym utworzeniu pliku dziennika. Jest to najszybsza / niższa metoda narzutu: operacje zmiany nazwy / przenoszenia są bardzo szybkie i mają stały czas wykonania. Co więcej, jest to prawie atomowa operacja: oznacza to, że (prawie) żaden wpis dziennika nie zostanie utracony podczas przenoszenia / przeładowywania. Z drugiej strony potrzebujesz procesu zdolnego do ponownego załadowania i ponownego otwarcia jego pliku dziennika. Rsyslog jest takim procesem, więc domyślna konfiguracja logrotate korzysta z metody reload. Używanie tego trybu z rsyslog jest zdecydowanie zalecane przez rsyslog w górę.
• copytruncate : stary plik dziennika jest kopiowany do pliku archiwum, a następnie jest obcinany w celu „usunięcia” starych linii dziennika. Chociaż operacja obcinania jest bardzo szybka, kopia może być dość długa (w zależności od tego, jak duży jest Twój plik dziennika). Co więcej, niektóre wpisy dziennika mogą zostać utracone w czasie między operacją kopiowania (pamiętaj, że może być powolne) i obcięciem. Z tych powodów copytruncate nie jest domyślnie używany w przypadku usług zdolnych do ponownego załadowania i odtworzenia ich plików dziennika. Z drugiej strony, jeśli serwer nie jest w stanie ponownie załadować / odtworzyć plików dziennika, copytruncate jest najbezpieczniejszym wyborem. Innymi słowy, nie wymaga wsparcia na poziomie usługi. Projekt rsyslog upstream zdecydowanie odradza korzystanie z tego trybu.

Mówiąc jako autor rsyslog, copytruncate jest w rzeczywistości bardzo, bardzo, bardzo złym wyborem. Jest z natury ostrożny, a korzystanie z niego jest prawie gwarancją utraty danych dziennika. Im częściej plik jest zapisywany, tym więcej stracisz. I to nie jest tylko część ostatniej linii, ale może być kilkaset, w zależności od dokładnego czasu i stanu systemu w momencie obrotu.

Po przeniesieniu pliku i utworzeniu nowego i-węzła (pliku) rsyslog śledzi poprzedni plik i kończy przetwarzanie. Więc w tym przypadku nie poniesiesz żadnych strat. Gwarantowane (chyba że odmontujesz system plików ...).

Na temat „reopenOnTruncate”: osobiście widziałem, że reopenOnTruncate jest również racjonalny pod innymi względami, szczególnie w przypadku NFS i tym podobnych. Jakiś czas temu całkowicie usunąłem tę funkcję, ale później przekonałem się do ponownego włączenia podobnej funkcjonalności. Pozostanie ona „eksperymentalna” najprawdopodobniej na zawsze, ponieważ naprawdę wiem, że ludzie mają problemy w bardzo mocno obciążonych systemach. „copytruncate” po prostu nie jest przyzwoitym trybem do pracy z plikami dziennika.

Obecnie pracuję nad plikiem refaktoryzacji (ETA 8.34 lub 8.35). Refaktoryzowana wersja prawdopodobnie będzie w stanie zapobiec przypadkowemu ponownemu wysłaniu z powodu wyścigu API, ale także nie będzie w stanie uchronić się przed utratą danych - ponieważ jest to koncepcyjnie niemożliwe.

Zależy to całkowicie od tego, jak proces zapisuje dzienniki.
copytruncatedziała tylko wtedy, gdy komunikaty dziennika są dołączane do pliku (np whatever >> logfile.
I nie wtedy, gdy przekierowuje dane wyjściowe (np whatever > logfile.).

Od wersji 8.16 rsyslog ma opcję imfile, reopenOnTruncatektóra obsługuje problem copytruncte.

W przypadku rsyslog prawdopodobnie bardziej sensowne jest pozostawienie rzeczy takimi, jakie są.

Podstawowym powodem jest to, że rsyslog ma wewnętrzne kolejki, których może używać w przypadkach, gdy jego uchwyt wyjściowy staje się niedostępny.

Przeładowanie a) spowoduje, że rsyslog odtworzy swój własny plik dziennika, i b) spowoduje, że wszelkie zdarzenia w kolejce zostaną opróżnione do pliku podczas tworzenia.

Możliwe, że copytruncate nie wyrządza szkody (chociaż martwi mnie to, że częściowo napisane linie są obcinane), ale zwykle uważam, że kopiowanie / usuwanie / przeładowywanie jest „bezpieczniejsze” z punktu widzenia integralności.

Jak wspomniał @ faker , ponieważ rsyslog może obsłużyć sytuację, w której jego plik staje się niedostępny, nie ma ważnego powodu, aby użyć copytruncate.

I jak wspomniano w @ SelivanovPavel , rsyslog faktycznie wymaga konkretnej konfiguracji, aby poprawnie poradzić sobie z obcinaniem kopii.

Więc choćby dlatego, że zastosowanie tego reloadpodejścia wymaga mniejszego odchylenia od domyślnej konfiguracji, zatrzymałbym to.