Откъде идва растежът на диска на VPN сървър и как да го ограничим

Тунелът спира да приема връзки, услугата се рестартира два пъти и след това в журнала ѝ не се появява нищо. Тази тишина е уликата, защото дискът е запълнен именно от журнала и демонът няма къде да запише грешката, която чакате. Всяка дълго работеща услуга може да стигне до това състояние, а изтриването на директория с име logs рядко го оправя. Трайното решение е да знаете кое хранилище е нараснало, кой отговаря за политиката му на съхранение и дали записващият наистина е освободил мястото.

Намерете хранилището, което е нараснало, и темпа на растежа му

Започнете с две числа, които лесно се забравят: свободни блокове и свободни inode. Една файлова система може да отчита много място и пак да откаже запис, защото не ѝ остават inode, а това се случва, когато услуга създава по един файл на сесия. Поискайте и двете стойности на един и същ том, защото отговорите могат да се разминат още същия следобед. Правете го, докато хостът е здрав, така че числата да описват нормална работа, а не авария.

df -h /var
df -i /var

След това отнесете растежа към конкретен собственик. Собствената стойност за използване на журнала покрива само журнала и никога няма да види демон, който пише по път от конфигурационния си файл.

journalctl --disk-usage

Растежът във времето казва повече от всяко отделно измерване. Оставено включено ниво за отстраняване на грешки, цикъл за повторни опити, който записва всеки опит, или файл за прихващане, който никой не е спрял: всяко от тях може да изглежда обикновено в един момент и тревожно час по-късно. Направете едно измерване, изчакайте натоварен период, направете второ и разделете на интервала. Темп, който можете да назовете, превръща капацитета в решение, а не в пожар.

Какво прави ротацията с отворен файл

Файлът на журнала е име, което сочи към inode, и мястото се връща само когато последният отворен дескриптор се затвори. Преименувайте файла и записващият продължава да пълни същия inode; изтрийте го и записващият продължава да пълни inode без никакво име. Точно това състояние обяснява защо „изтрих файла, а дискът остана пълен“ описва файлови дескриптори, а не счупена файлова система. Рестартирането на записващия или изборът на режим на ротация, който отваря файла наново, е това, което наистина връща блоковете.

lsof +L1 | head

Политиката принадлежи на компонента, който пише файла. Журналът налага собствените си ограничения за съхранение от конфигурационния си файл, докато услуга, базирана на файлове, обикновено разчита на logrotate или с правило за създаване и сигнал за повторно отваряне, или с режим на съкращаване на място, когато записващият не може да отвори файла наново. Първо потвърдете решението, без да променяте нищо:

logrotate -d /etc/logrotate.conf

Къде принадлежи ограничението и колко голямо трябва да е

Сложете ограничението там, където е конфигуриран записващият, а не в точката на монтиране. Квота за целия том защитава хоста, но не казва коя услуга ще се провали първа, а глобален скрипт за почистване обикновено изтрива доказателствата, нужни за следващия инцидент. Ограничение на журнала, брой ротации с максимален размер и съхранение на ниво приложение: всяко от тях ограничава един производител. Заедно те ограничават общото; поотделно всяко е предположение.

Определяйте размера на ограничението от срока за съхранение, който можете да защитите, а не от свободното място. Ако за проверка са нужни седмица опити за връзка, журналът трябва да държи седмица при най-високия очакван темп, а този темп е числото, измерено по-рано.

Журналът за отстраняване на грешки е временен режим с записано начално време, а не план за съхранение. Дръжте въпроса за поверителността в същото решение, защото журналите на връзките носят адреси и идентификатори. По-дългото съхранение също е избор за обработка на данни и трябва да го направи човек, който познава и двете ограничения.

Проверете ограничението след рестарт

Промяна в съхранението, която издържа до следващия рестарт, не е промяна. Рестартирайте записващия, потвърдете, че новият лимит влиза в сила, и проверете, че ротацията все още работи след това. За журнала един рестарт и едно измерване на използването отговарят на двата въпроса:

systemctl restart systemd-journald
journalctl --disk-usage

За услуга, базирана на файлове, стартирайте задачата за ротация веднъж на ръка и потвърдете, че файлът е заменен и дескрипторът е отворен наново. Записващ, който държи стария дескриптор, минава повърхностна проверка и се проваля следващия път, когато томът се напълни. Наблюдавайте свободното място по време на теста, защото файл, който е намалял, а мястото не се е върнало, означава, че старият inode още се държи.

Сравнете следващото измерване с това

Върнете се след седмица и сравнете темпа на растеж със записания. Съвпадащ темп означава, че ограничението държи и натоварването е стабилно; удвоен темп означава, че нещо се е променило, и полезният въпрос е какво. Първо прочетете съдържанието на журнала за повтарящи се откази, защото цикълът за повторни опити е едновременно симптом и причина за обем. След това проверете за всичко ново включено, включително нива за отстраняване на грешки, включени по време на инцидент и никога не изключени.

Дръжте резервните копия извън същия том или приемете, че един пълен диск ще отнесе и копието. Копие, записано на хоста, който то защитава, не е план за възстановяване, и съхранението му изисква собствен отговор.

Запишете какво се съхранява, къде, колко дълго и кой го премахва. Това изречение е резултатът и е единствената част от тази работа, която оцелява след следващия рестарт.