Кому принадлежат журналы 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 остаётся авторитетной для собственных параметров журналирования демона. Ни одна из них не решает вашу политику хранения за вас.

Проверьте одну ротацию и одно новое событие

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

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

Завершите, записав владельца каждого шага: какой компонент пишет, какой ротирует и где живёт политика хранения. Именно эта запись превращает следующий инцидент с журналами в пятиминутную проверку вместо половины дня догадок о том, какой слой потерял строку.