Ротация на дневник на VPN наблюдател без счупване на записващия процес

Проверка на здравето на 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, и никаква подредба за журнал не бива да е причина работещ тунел да бъде рестартиран.