Кой притежава журналите на OpenVPN: демонът, rsyslog или logrotate?

Ротацията на журналите се чупи по предвидим начин: три компонента всеки смята, че притежава файла, и резултатът е ротиран журнал, който продължава да расте, докато новият остава празен. Демонът държи дескриптор, logrotate преименува пътя, а rsyslog пише съвсем другаде. Изберете един писател и един ротатор, преди да добавите още едно правило към купчината. Контролният списък по-долу върви в този ред, защото всяка следваща стъпка зависи от него.

Решете кой пише файла

Има два законни варианта. При първия процесът на VPN сам пише файл чрез своята опция log или log-append. При втория изпраща записи към системния журнал и rsyslog или journald решава къде да попаднат.

Това са алтернативи, а не слоеве. Хост, който включи и двете, се сдобива с два файла, които не съвпадат, и този, който четете, често е остарелият. Изберете пътя нарочно, после премахнете другия писател.

Прочетете действащата конфигурация на услугата, преди да промените каквото и да е, включително drop-in файловете, които може да заместват unit файла. Директива в профила, който редактирахте, не е доказателство, че е тази, която работещият процес е заредил. Сравнете unit файла с аргументите на процеса, а после с файловете, които той действително е отворил.

Назовайте демона, за да е тесен филтърът

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

Тесните правила правят отговорим и следващия въпрос: коя услуга е създала този ред? Филтър, който съвпада с всичко, съдържащо думата VPN, с готовност ще събере трафика на втори тунел и ще замъгли и двата. Съпоставяйте по точния идентификатор, който unit файлът подава на журнала.

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

Ротирайте, без да губите дескриптора

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

Решението е действие postrotate, което задейства документираното поведение за презареждане или рестарт на услугата. Изпращането на сигнал до журнала е съвсем друго действие и не прави нищо за демон, който държи собствен файл.

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

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

Задайте съхранението от прозореца на инцидента

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

Дръжте политиката на едно място. Ако logrotate ротира файла и rsyslog също го ротира, печели втората ротация и схемата за имена на първата оцелява като бъркотия. Изберете собственика, изключете другата ротация и отбележете това решение до политиката.

Документацията на rsyslog покрива модела му за маршрутизиране и действия, докато документацията на услугата OpenVPN остава меродавна за собствените опции за журналиране на демона. Нито една от двете не решава политиката ви за съхранение вместо вас.

Тествайте една ротация и едно ново събитие

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

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

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