Проверка на здравјето на VPN што додава по една линија во минута тивко создава втора должност: да се одлучи како тие линии го напуштаат дискот. Поправањето на тунелот не прави ништо за таа должност, а преименувањето на датотеката не пренасочува процес што уште го држи стариот дескриптор. Прво одговорете на прашањето за целта, потоа усогласете ја ротацијата со начинот на кој запишувачот ја отвора.

Изберете ја целта пред политиката за ротација

systemd единица што веќе го праќа својот излез во дневникот го чува задржувањето на едно место. journald наметнува граници како SystemMaxUse и MaxRetentionSec , па чуварот што логира таму наследува граница без дополнителна работа. Додавањето втора неограничена датотека до него го удвојува одржувањето без корист.

Посветена датотека го заслужува своето место кога нешто друго ја чита: парсер, извоз за ревизија или страница што очекува стабилна патека. Откако таа одлука е донесена, на датотеката ѝ требаат сопственик, режим и политика за ротација напишани заедно, бидејќи трите се точни само како множество. Патека што секој може да ја создаде е и патека што секој може да ја замени, затоа дозволите на директориумот припаѓаат во истата белешка. Запишете го сето тоа до проверката и следното уредување ќе започне од истите факти.

Напишете го блокот за да одговара на запишувачот

Започнете со запишувач што ја отвора патеката при секое повикување, додава линија и излегува. Тој образец ја преживува ротацијата без никаква соработка од процесот, бидејќи следното извршување ја отвора датотеката што моментално стои на таа патека. Блокот подолу чува една недела верзии и ја создава датотеката повторно со сопственикот и режимот што му се потребни на запишувачот:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

Прирачникот на logrotate го дефинира бројот како број на задржани ротирани верзии, а не како гаранција за седум дена историја, а клучниот збор daily се оценува кога задачата се извршува наместо да дејствува како сопствен планер. На повеќето дистрибуции systemd тајмер или cron запис веќе го поседува тоа повикување, затоа проверете кој постои пред да додадете втор. Совпаѓањето на сопственоста е поважно од бројот на задржување. Копирањето режим само за root на датотека што ја пишува сервисна сметка го запре логирањето при следната ротација, а дефектот се појавува часови подоцна како застарен временски печат, а не како грешка. Потврдете го корисникот на запишувачот пред да копирате блок од друго место.

Запишувач што никогаш не отвора повторно бара друг лек

Долготраен процес што држи отворен дескриптор продолжува да пишува во преименуваниот inode. Просторот не се ослободува и видливата датотека престанува да расте, што изгледа како расипана ротација додека не го проверите inode. Или научете го процесот повторно да отвора, или направете ротацијата да копира и отсекува наместо да преименува.

Патеката на повторно отворање е почиста таму каде што софтверот ја поддржува: испратете го документираниот сигнал или извршете ја документираната команда и оставете процесот сам да ја отвори новата датотека. Алтернативата е copytruncate , која ја копира содржината во ротираното име и потоа го отсекува оригиналот на место, така што дескрипторот останува валиден, но записите што паѓаат помеѓу копирањето и отсекувањето се губат.

За единиците што ги стартува systemd, насочете StandardOutput кон дневникот или кон датотека и оставете единицата да го поседува животниот циклус. Shell циклус што додава преку tee -a без ограничување на големината е распоредот што за време на прекин ја полни партицијата, бидејќи неуспешната проверка често логира многу повеќе од здрава.

Тестирајте ја ротацијата без да го чекате тајмерот

Режимот за отстранување грешки известува што би се случило и не допира ништо, што го прави безбедното прво извршување по уредување. Присилете вистинска ротација кога сте задоволни, потоа потврдете дека следната линија од дневникот паѓа во новата датотека, а не во преименуваната:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

Прочитајте го излезот по тој редослед. Преминот за отстранување грешки треба да ја именува датотеката и предвидените дејства; присилното извршување треба да го создаде очекуваното ротирано име; tail треба да покаже нов запис откако запишувачот повторно ќе работи. Растечка вредност на df со намалување на видливата датотека значи проблемот со дескрипторот опишан погоре.

Повторете го присилното извршување двапати за да видите како се однесува задржувањето кога верзиите веќе постојат. Бришењето на најстарата датотека е очекуваниот резултат, а изостанатото бришење обично значи дека бројот или џокерот во ротираното име не се совпаѓаат со она што го создал logrotate.

Зачувајте можност за враќање и писмен запис

Зачувајте го претходниот блок пред уредување и забележете кој планер го извршува, бидејќи враќањето што ја враќа датотеката но не и тајмерот репродуцира половина од првобитниот проблем. По враќањето заротирајте еднаш рачно, потоа потврдете дека сметката на запишувачот може да пишува на патеката на дневникот. Ако услугата работи под systemd, вчитајте ја единицата повторно по секоја промена на пренасочувањето на нејзиниот излез, бидејќи процесот што работи продолжува да пишува на старата цел. Прочитајте ги следните неколку линии од дневникот сами, наместо да верувате дека единицата се вратила чисто.

Запишете ги режимот, сопственикот, бројот на задржување и очекуваниот диск-буџет до самата проверка. Кога подоцна проверката ќе се смени од еднократна скрипта во демон, политиката за ротација мора да се смени со неа, и таа белешка му кажува на следниот човек која претпоставка се скршила.

На крајот, држете ја одлуката за дневникот одвоена од одлуката за обновување. Неуспешната проверка треба да ја следи сопствената политика за обновување на врската, а не правило скриено во logrotate, и ниту еден распоред за логирање не треба да биде причина работен тунел да се рестартира.

Поврзани статии